Survey: Software Defined Networks with Emphasis on Network Monitoring

Transcription

1 Survey: Software Defined Networks with Emphasis on Network Monitoring Prashanth Indian Institute of Technology, Bombay (IIT-B) Powai, Mumbai, Maharastra India 31 Oct 2015 Abstract Software Defined Networks (SDN) has been the buzz word in the networking industry for quite sometime now. What it really is - A technique used in Computer Networking to provide an abstraction between control and data planes in networking equipments present along a network. It tries to simply the process of network management for network administrators by providing programmability in managing networks. This paper surveys majority of the developments so far in SDN with emphasizes on a protocol called OpenFlow and a network monitoring framework namely - PayLess. OpenFlow specifies a protocol developed over a Switch with flow tables extended by adding on an interface to make updates to these tables. An extension to this is PayLess: a network monitoring framework developed for SDNs built on top of OpenFlow. The survey tries to provide a comparison of the various metrics like accuracy, timeliness and overhead based on which Payless was tuned upon. It also provides a brief outline into the evaluation sections provided by the papers which were surveyed. Keywords Software Defined Networks, Survey, Programmable Networks, OpenFlow, PayLess, Network Monitoring, Data Plane, Control Plane

2 Chapter 1 Introduction 1.1 Background The Internet today is Network of Networks and undoubtedly is a the largest network present today. A computer network is made up of several different types of networking devices connected to each other using communication channels. There are network administrators who manually transform these high level requirements into low-level configuration settings to enable connectivity between networking devices. This task of setting up of networks by administrators is often tedious and error-prone. There are a lot of new proposals and techniques proposed by researchers on improving the existing Internet but, it s often difficult to implement these over the Internet and most of the research work goes untried which is due to the classic problem of Internet Ossification. Currently temporary alternatives using middle-boxes (NATS, Firewall etc.) are implemented to bypass this, but this wouldn t help the problem for the long run. To overcome this problem, a nationwide research facility for experimenting new architectures was proposed by GEN1 [1]. In this approach a researcher would allocate a slice of his networking resources dedicated for this architecture. But this approach seemed to be expensive and time taken to implement such a design would be tremendous. The ideology of Programmable Networks had come around a while back. In 2006, Ethane [2] was proposed which laid the basis for SDN. Finally this lead to the introduction of Software Defined Networking (SDN) which was a new networking paradigm in which the forwarding hardware is decoupled from control decisions [3]. For the sake of simplicity, all switches (L2, L3, L4) here after would be referred as switches. 1.2 Problems Addressed As already mentioned above, it was getting difficult to test out new research proposals and SDN [3] had come up with a methodology for connecting and communicating between networks by placing the control logic in a centralized entity called controller (control plane) and only storing the forwarding information on the switches (data plane). This seems to be a perfect solution to address our initial problem. This again lead to another problem of modifying the switches to accommodate this change. Most vendors were very shy to about opening up interfaces to researchers in applying their algorithms from fearing that it would disturb their native traffic flow. This lead to the emergence of OpenFlow Switches [4] which exploits the fact that switches contain flowtables which have a set of common functionalities by dividing the flows into production and research based flows. The network vendors now provided an interface on OpenFlow enabled switches through which OpenFlow protocol can be used to communicate with the switches. Network monitoring is an necessary functionality in networks. It helps management in achieving tasks like load balancing, Traffic engineering, enforcing SLA s, Accounting, Intrusion Detection etc. [5] The collection of data may occur at different scales and levels. Some of these cause minimal and some cause tremendous network overhead. These methods can be classified as Direct and Sample based [6] [7]. OpenFlow provides a per flow statistics collection mechanism, but doesn t specify available the trade-off between accuracy and network overhead. Payless takes advantage of statistics provided by OpenFlow to develop a more robust framework over which designers can build customized application for network monitoring purposes to target the right balance between accuracy and overhead depending on their requirements. Putting it all together 3 papers were reviewed and the order in which papers were reviewed in the following sequence - Survey of SDN [3], OpenFlow [4], PayLess [5] in order to maintain a continuous flow. Each of them is explained in detail in the upcoming section. 1

3 Chapter 2 Survey Details 2.1 Overview of SDN Ethane [2] was responsible for putting forward the initial idea of SDN methodology. The current section describes the current stand out on SDN with respect to details provided by A survey of SDN: Past, Present and Future of Programmable Networks [3] Architectures The architecture of SDN revolves around the idea of separation of switches from the control logic hence providing network administrators a more boarder control over the network. Current well-known architectures for SDN are OpenFlow [4] and ForCES [8]. ForCES was proposed by IETF ForCES (Forwarding and Control Element Separation) work group. In ForCES the switch is still represented as a single entity with separation of data plane and allowing a thirdparty control for controller within the same device. It speaks of two entities namely, Control Entity (CE) and forwarding entity (FE). FE is responsible for processing incoming packets at the data plane, whereas CE is responsible for signaling functions using ForCES protocol to the CE. They together form a master-slave architecture. On contrary OpenFlow separates the switch (data place) and controller (control plane) and tries to centralize (locally or globally) the controller. Forwarding logic used by ForCES depends on Logical Functional Blocks whereas OpenFlow relies on flow tables. More about OpenFlow is specified in the upcoming sections Data Plane Devices such as switches, routers, WAP, Gateways etc. make up the data plane and we will address them as simply switches as mentioned earlier. Switches are of two types 1. Pure: Relay on controller for forwarding decisions 2. Hybrid: Try to process packets primarily through OpenFlow forwarding tables and in-case of no match makes use of traditional forwarding mechanism Control Plane Control plane comprises of one or more controllers depending on the architecture implemented. They provide a programmable interface to the network. The general assumption is that controller is a centralized entity. The decentralization of controller is a possible approach. Typically a switch is connected to one or more controller in which one of them is the primary one and others are backup controllers. Applications can be built in various programming languages to interact with the controller. Controllers have to consider two of the below options in them namely 1. Granularity: Decision making granularity based on packets, flows etc. which creates a network overhead at different rates 2. Reactive or proactive policies: Reactive controllers are consulted each time a new flow arrives whereas proactive actively pushes forwarding logic from controller to switches in advance The controller has to also implement north bound and south bound interfaces. North bound interface exposes functionalities to the Applications developers and south bound interface allows controller-switch communications. 2

4 2.2. OpenFlow 3 Figure 2.1: Communication between controller and forwarding device using SDN architecture 2.2 OpenFlow OpenFlow [4] exploits the fact that routers of present day run different flow tables but interestingly have a common set of functions that run in most of the switches. OpenFlow exposes a protocol which can be used to program switches. Typically the network administrator partitions flows into research and productions there by minimizing the possibility of disrupting production traffic. Production traffic is isolated from research traffic and is handled natively by the switch. An OpenFlow switch typically consists of the following three parts refer Fig: 2.1 [4] for more details, 1. Flow table consisting of action pertaining the each flow 2. A secure channel that connects switch to remote controller 3. OpenFlow protocol which is used to communicate between the switch and controller Exposing an standard interface to program the switch eliminates the challenge researchers face in programming the switches. As in the case of two different kinds of switches mentioned in typical SDN data plane mentioned in Sec: 2.1.2, the OpenFlow classifies switches as 1. Dedicate OpenFlow switches: Exclusively meant for OpenFlow 2. OpenFlow enabled switches: Implements OpenFlow flow tables on top native network Switch supports the following four actions based on the type of switch. The first 3 corresponds to both types of switches and the last one corresponds to OpenFlow enabled switches, 1. Forward the flow s packet to a given port 2. Typically the first packet of the flow is encapsulated and forwarded to the controller to decide on the action to be taken corresponding to that particular flow 3. Dropping of flow packets 4. Forwards the flow packets using native routing table A flow table entry has three fields - header that defines the flow, the action corresponding to it, and statistics for that flow. When a switch supports all four actions and its entries have the three fields, such a switch is referred to as Type 0 switch. Switches which support additional options like NATing etc. along with above are called Type 1 switches. A controller modifies flows present in a switch using the OpenFlow protocol. Remember that OpenFlow only specifies the protocol between switch and controller and also doesn t specify protocols regarding multiple/distributed controllers, the network designer has to accommodate for these.

5 2.3. PayLess - Network Monitoring Framework 4 Figure 2.2: PayLess Network Monitoring Framework 2.3 PayLess - Network Monitoring Framework Overview PayLess [5] focuses on trade-off between monitoring accuracy, timeliness, and network overhead by providing a more robust network monitoring framework built on top of existing controller on the north bound interface and provides a high-level RESTful API. This framework could be used for developing a range of network monitoring applications with a variable rate sampling algorithm. The current controllers don t provide the diversity in number of aggregations levels which are exposed and supported by PayLess. Fig: 2.2 [5] shows various components present in PayLess and have been described below, 1. Request Interpreter: Translates complex instructions given by applications to flow level primitives. 2. Scheduler: Determines the type of statistics to poll. Time-stamps for polling is determined by scheduling algorithm. It even provides the flexibility to develop custom algorithms. 3. Switch Selector: Makes a list of switches which have to monitored to collect required statistics. 4. Aggregator & Data Store: Aggregates data from selected switches and stores them into data stores. PayLess exposes a flexible RESTful API which could be programmed making use of any programming language. An application must create a Monitoring Request object and register it with the framework. The request object can contain the following information about monitoring task - Type, Metrics, Aggregation level, Priority, Monitor, Logging, Entity(Optional). This request is specified using JSON. After registering the request, PayLess returns an object-id which can be used to access the required data by the requesting application Adaptive Monitoring Method PayLess proposes an adaptive algorithm by virtue of which the controller adds a flow new entry for every PacketIn message to the flow table of corresponding switch and also with initial statical timeout of τ milliseconds. If data collected doesn t show significant change with time the timeout for flow is multiplied by a small constant α hence increasing the timeouts for data collection. This goes on decreasing until it reaches τ min after which it stagnates. Similarly when flow traffic increases in a link τ is divided by a constant β until it reaches τ max. Using this algorithm, higher pooling frequency is provided to flows that contribute more and vice-versa. This algorithm is further optimized by batching the FlowStatisticsRequest messages.

6 Chapter 3 Evaluation of Experiments 3.1 Survey of SDN The first paper A survey of SDN: Past, Present and Future of Programmable Networks [3] was a survey paper and hence didn t provide an experimental section. 3.2 OpenFlow The OpenFlow [4] proposed 5 different scenarios in which experiments could be performed but didn t actually implement these scenarios. The following are the experiments that were proposed by the paper 1. Network management and access control: Extension of ethane in which a particular flow in network is sent to user space process in a controller 2. VLANs: Setting up of VLANs which maybe statically or dynamically implemented 3. Mobile wireless VOIP Clients: Mobile users connected to a WiFi implementing OpenFlow to have seamless hand-offs across switches 4. Non-IP Network: Using Non-IP packets to route packets in an SDN network by handling their own packet header type 5. Packet Processing: Processing packets with the help of an IDS like system making use of making all packets pass through the controller or a dedicated switch used for this purpose The following experiments should ve been implemented and their findings must have been tabulated and plotted to provide from practical evidence for the theoretical concepts provided in the paper. It could ve demonstrated an experiment where packets where routed natively (production flows) as well as through flow tables (research flows) using the same switch effectively without disrupting the normal network services. The experimental section clearly lacks evidence to back concepts described in the paper. 3.3 PayLess The experiments performed on PayLess [5] was done with keeping its existing competing framework FlowSense [9] in mind. Mininet was used to simulate the setup consisting of hosts and OpenFlow switch. For the purpose of experiment a tree topology was chosen with τ min = 5s and τ max = 500ms. β was set to a higher value to quickly react to changes. The evaluation metrics chosen were Link utilization and Overhead. PayLess successfully changed its polling period based on link utilization. It was also observed that link utilization reported by adaptive algorithm proposed by PayLess was more close to that reported by periodic polling (actual utilization) than by FlowSense. It provided higher accuracy than flow sense and close to periodic polling but only utilized half overhead as mush as periodic polling. It must be noted that FlowSense provided nearly zero overhead but by compromising on accuracy. Furthermore, FlowSense can be customized by developers as per requirements. Among the 3 papers which were reviewed PayLess satisfies most number of requirements needed by any basic experimental section but then again the experiments could have covered a larger test set by implementing the framework in real situations like Data Centers, ISPs etc. 5

7 Chapter 4 Conclusions and Unresolved Problems Software Defined Networks is an interesting concept which solves one of our major problem to testing out research based solutions on present day networks. Keeping that mind, there are a few challenges that still need refinement in this area. SDN only specifies a protocol running between controller and switch interactions but not about other communications in the network. Certain guidelines/rules could be specified about running different protocols between other communication links in an SDN. It raises significant scalability, performance, robustness and reliability challenges [3]. The placement of controllers and number of controllers required in different networks has to be addressed. Application of different policies to the same flow could be accommodated for. SDN could impact virtualization by making critical impacts in live migration [10], design of HA systems etc. Infrastructure based developments projects such as OpenRoads Project [11] where users can move between networks is an another insightful idea in the long run. OpenFLow is the right choice for commercial deployment as it requires no hardware changes to the existing harware. Standardization of a protocol like OpenFlow [4] into commercial networking devices must be given high priority. The sooner this is standardized, greater will be the support from the commercial vendors in backing research based developments in the field of networking. The OpenFlow Consortium has been trying to achieve the same for a while now trying to standardize OpenFlow. Researchers are also trying to develop a more robust version of OpenFlow called OpenFlow 2.0. PayLess [5] has been a flexible and robust framework that caters to the needs of application developers who are interested in monitoring a SDN based network. PayLess can be extended to a more full-fledged framework by more providing more functionalities and finally could be standardized once its stable enough. PayLess right now doesn t support distributed controllers which should be taken care of in the near future as more and more SDN networks are focusing on distributed controllers are is reduces the controller overhead and also provides a backup mechanism in case of failure of the primary controller. Lastly, we could conclude by mentioning that SDN is a brilliant idea to solve the existing problem of Internet Ossification and has brought out some of the most desirable features from existing networks without making much changes to it. But then again lot of it are still mere concepts and haven t been tested enough to be standardized and hence more research has to be done on its flexibility and feasibility. Finally the research community has to come up with a set of standards to make the growth of networks more effective to different domains. 6

8 Bibliography [1] Global environment for network innovations. [2] M. Casado, M. J. Freedman, J. Pettit, J. Luo, N. McKeown, and S. Shenker, Ethane: taking control of the enterprise, in ACM SIGCOMM Computer Communication Review, ACM, vol. 37, 2007, pp [3] B. Nunes, M. Mendonca, X.-N. Nguyen, K. Obraczka, T. Turletti, et al., A survey of software-defined networking: past, present, and future of programmable networks, Communications Surveys & Tutorials, IEEE, vol. 16, no. 3, pp , [4] N. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson, J. Rexford, S. Shenker, and J. Turner, Openflow: enabling innovation in campus networks, ACM SIGCOMM Computer Communication Review, vol. 38, no. 2, pp , [5] S. R. Chowdhury, M. F. Bari, R. Ahmed, and R. Boutaba, Payless: a low cost network monitoring framework for software defined networks, in Network Operations and Management Symposium (NOMS), 2014 IEEE, IEEE, 2014, pp [6] Cisco netflow. html. [7] Traffic monitoring using sflow. [8] L. Yang, R. Dantu, T. Anderson, and R. Gopal, Forwarding and control element separation (forces) framework, Tech. Rep., [9] C. Yu, C. Lumezanu, Y. Zhang, V. Singh, G. Jiang, and H. V. Madhyastha, Flowsense: monitoring network utilization with zero measurement cost, in Passive and Active Measurement, Springer, 2013, pp [10] E. Keller, S. Ghorbani, M. Caesar, and J. Rexford, Live migration of an entire network (and its hosts), in Proceedings of the 11th ACM Workshop on Hot Topics in Networks, ACM, 2012, pp [11] K.-K. Yap, R. Sherwood, M. Kobayashi, T.-Y. Huang, M. Chan, N. Handigol, N. McKeown, and G. Parulkar, Blueprint for introducing innovation into wireless mobile networks, in Proceedings of the second ACM SIGCOMM workshop on Virtualized infrastructure systems and architectures, ACM, 2010, pp