Software-defined networking

From Wikipedia, the free encyclopedia
  (Redirected from Software-defined network)
Jump to: navigation, search

Software-defined networking (SDN) is an approach to computer networking that allows network administrators to manage network services through abstraction of lower level functionality. This is done by decoupling the system that makes decisions about where traffic is sent (the control plane) from the underlying systems that forward traffic to the selected destination (the data plane). The inventors and vendors of these systems claim that this simplifies networking.[1]

SDN requires some method for the control plane to communicate with the data plane. One such mechanism, OpenFlow, is often misunderstood to be equivalent to SDN, but other mechanisms could also fit into the concept.

History[edit]

Software Defined Networking (SDN) was born with work done in 2003 by Bob Burke and Zac Carman developing the Content Delivery Control Network patent application that eventually was issued as US patent 8,122,128.[2] In this seminal inception, Software Defined Networking, named Service Preference Architecture (SPA) in their Patent, was described as a collection of network embedded computing techniques used to control the operation of Network Elements, namely content servers, routers, switches and gateways, with the objective being to safeguard content from theft (P2P) or unwanted interception and to efficiently deliver content for paid services. CableLabs later specified Digital Cable and CableCARD using what we now know as SDN, which debuted in 2007. SDN was again moved ahead in work done at UC Berkeley and Stanford University around 2008.[3]

The Open Networking Foundation was founded in 2011 to promote SDN and OpenFlow.

At the 2014 Interop and Tech Field Day software-defined networking was demonstrated by Avaya using Shortest path bridging and OpenStack as an automated campus, extending automation from the data center to the end device, removing manual provisioning from service delivery.[4][5]

Concept[edit]

[6] Software-Defined Networking (SDN) is an emerging architecture purporting to be dynamic, manageable, cost-effective, and adaptable, seeking to be suitable for the high-bandwidth, dynamic nature of today's applications. SDN architectures decouple network control and forwarding functions, enabling network control to become directly programmable and the underlying infrastructure to be abstracted from applications and network services.

The OpenFlow protocol is a foundational element for building SDN solutions. The SDN architecture is:

  • Directly programmable: Network control is directly programmable because it is decoupled from forwarding functions.
  • Agile: Abstracting control from forwarding lets administrators dynamically adjust network-wide traffic flow to meet changing needs.
  • Centrally managed: Network intelligence is (logically) centralized in software-based SDN controllers that maintain a global view of the network, which appears to applications and policy engines as a single, logical switch.
  • Programmatically configured: SDN lets network managers configure, manage, secure, and optimize network resources very quickly via dynamic, automated SDN programs, which they can write themselves because the programs do not depend on proprietary software.
  • Open standards-based and vendor-neutral: When implemented through open standards, SDN simplifies network design and operation because instructions are provided by SDN controllers instead of multiple, vendor-specific devices and protocols.

Limitations of current networking technologies[edit]

Meeting current market requirements is virtually impossible with traditional network architectures. Faced with flat or reduced budgets, enterprise IT departments are trying to squeeze the most from their networks using device-level management tools and manual processes. Carriers face similar challenges as demand for mobility and bandwidth explodes; profits are being eroded by escalating capital equipment costs and flat or declining revenue. Existing network architectures were not designed to meet the requirements of today’s users, enterprises, and carriers; rather network designers are constrained by the limitations of current networks, which include:

  • Complexity that leads to stasis: Networking technology to date has consisted largely of discrete sets of protocols designed to connect hosts reliably over arbitrary distances, link speeds, and topologies. To meet business and technical needs over the last few decades, the industry has evolved networking protocols to deliver higher performance and reliability, broader connectivity, and more stringent security. Protocols tend to be defined in isolation, however, with each solving a specific problem and without the benefit of any fundamental abstractions. This has resulted in one of the primary limitations of today's networks: complexity. For example, to add or move any device, IT must touch multiple switches, routers, firewalls, Web authentication portals, etc. and update ACLs, VLANs, quality of services (QoS), and other protocol-based mechanisms using device-level management tools. In addition, network topology, vendor switch model, and software version all must be taken into account. Due to this complexity, today's networks are relatively static as IT seeks to minimize the risk of service disruption. The static nature of networks is in stark contrast to the dynamic nature of today's server environment, where server virtualization has greatly increased the number of hosts requiring network connectivity and fundamentally altered assumptions about the physical location of hosts. Prior to virtualization, applications resided on a single server and primarily exchanged traffic with select clients. Today, applications are distributed across multiple virtual machines (VMs), which exchange traffic flows with each other. VMs migrate to optimize and rebalance server workloads, causing the physical end points of existing flows to change (sometimes rapidly) over time. VM migration challenges many aspects of traditional networking, from addressing schemes and namespaces to the basic notion of a segmented, routing-based design. In addition to adopting virtualization technologies, many enterprises today operate an IP converged network for voice, data, and video traffic. While existing networks can provide differentiated QoS levels for different applications, the provisioning of those resources is highly manual. IT must configure each vendor's equipment separately, and adjust parameters such as network bandwidth and QoS on a per-session, per-application basis. Because of its static nature, the network cannot dynamically adapt to changing traffic, application, and user demands.
  • Inconsistent policies: To implement a network-wide policy, IT may have to configure thousands of devices and mechanisms. For example, every time a new virtual machine is brought up, it can take hours, in some cases days, for IT to reconfigure ACLs across the entire network. The complexity of today's networks makes it very difficult for IT to apply a consistent set of access, security, QoS, and other policies to increasingly mobile users, which leaves the enterprise vulnerable to security breaches, non-compliance with regulations, and other negative consequences.
  • Inability to scale: As demands on the data center rapidly grow, so too must the network grow. However, the network becomes vastly more complex with the addition of hundreds or thousands of network devices that must be configured and managed. IT has also relied on link oversubscription to scale the network, based on predictable traffic patterns; however, in today's virtualized data centers, traffic patterns are incredibly dynamic and therefore unpredictable. Mega-operators, such as Google, Yahoo!, and Facebook, face even more daunting scalability challenges. These service providers employ large-scale parallel processing algorithms and associated datasets across their entire computing pools. As the scope of end-user applications increases (for example, crawling and indexing the entire World Wide Web to instantly return search results to users), the number of computing elements explodes and data-set exchanges among compute nodes can reach petabytes. These companies need so-called hyperscale networks that can provide high-performance, low-cost connectivity among hundreds of thousands—potentially millions—of physical servers. Such scaling cannot be done with manual configuration. To stay competitive, carriers must deliver ever-higher value, better-differentiated services to customers. Multi-tenancy further complicates their task, as the network must serve groups of users with different applications and different performance needs. Key operations that appear relatively straightforward, such as steering a customer's traffic flows to provide customized performance control or on-demand delivery, are very complex to implement with existing networks, especially at carrier scale. They require specialized devices at the network edge, thus increasing capital and operational expenditure as well as time-to-market to introduce new services.
  • Vendor dependence: Carriers and enterprises seek to deploy new capabilities and services in rapid response to changing business needs or user demands. However, their ability to respond is hindered by vendors' equipment product cycles, which can range to three years or more. Lack of standard, open interfaces limits the ability of network operators to tailor the network to their individual environments.

This mismatch between market requirements and network capabilities has brought the industry to a tipping point. In response, the industry has created the Software-Defined Networking (SDN) architecture and is developing associated standards.

The need for a new network architecture[edit]

The explosion of mobile devices and content, server virtualization, and advent of cloud services are among the trends driving the networking industry to reexamine traditional network architectures.[7] Many conventional networks are hierarchical, built with tiers of Ethernet switches arranged in a tree structure. This design made sense when client-server computing was dominant, but such a static architecture is ill-suited to the dynamic computing and storage needs of today’s enterprise data centers, campuses, and carrier environments. Some of the key computing trends driving the need for a new network paradigm include:

  • Changing traffic patterns': Within the enterprise data center, traffic patterns have changed significantly. In contrast to client-server applications where the bulk of the communication occurs between one client and one server, today's applications access different databases and servers, creating a flurry of "east-west" machine-to-machine traffic before returning data to the end user device in the classic "north-south" traffic pattern. At the same time, users are changing network traffic patterns as they push for access to corporate content and applications from any type of device (including their own), connecting from anywhere, at any time. Finally, many enterprise data centers managers are contemplating a utility computing model, which might include a private cloud, public cloud, or some mix of both, resulting in additional traffic across the wide area network.
  • The "consumerization of IT": Users are increasingly employing mobile personal devices such as smartphones, tablets, and notebooks to access the corporate network. IT is under pressure to accommodate these personal devices in a fine-grained manner while protecting corporate data and intellectual property and meeting compliance mandates.
  • The rise of cloud services: Enterprises have enthusiastically embraced both public and private cloud services, resulting in unprecedented growth of these services. Enterprise business units now want the agility to access applications, infrastructure, and other IT resources on demand and à la carte. To add to the complexity, IT's planning for cloud services must be done in an environment of increased security, compliance, and auditing requirements, along with business reorganizations, consolidations, and mergers that can change assumptions overnight. Providing self-service provisioning, whether in a private or public cloud, requires elastic scaling of computing, storage, and network resources, ideally from a common viewpoint and with a common suite of tools.
  • "Big data" means more bandwidth: Handling today's "big data" or mega datasets requires massive parallel processing on thousands of servers, all of which need direct connections to each other. The rise of mega datasets is fueling a constant demand for additional network capacity in the data center. Operators of hyperscale data center networks face the daunting task of scaling the network to previously unimaginable size, maintaining any-to-any connectivity without going broke.

Architectural components[edit]

The following list defines and explains the architectural components[8]

architecture diagram
  • SDN Application (SDN App): SDN Applications are programs that explicitly, directly, and programmatically communicate their network requirements and desired network behavior to the SDN Controller via a northbound interface (NBI). In addition they may consume an abstracted view of the network for their internal decision making purposes. An SDN Application consists of one SDN Application Logic and one or more NBI Drivers. SDN Applications may themselves expose another layer of abstracted network control, thus offering one or more higher-level NBIs through respective NBI agents.
  • SDN Controller: The SDN Controller is a logically centralized entity in charge of (i) translating the requirements from the SDN Application layer down to the SDN Datapaths and (ii) providing the SDN Applications with an abstract view of the network (which may include statistics and events). An SDN Controller consists of one or more NBI Agents, the SDN Control Logic, and the Control to Data-Plane Interface (CDPI) driver. Definition as a logically centralized entity neither prescribes nor precludes implementation details such as the federation of multiple controllers, the hierarchical connection of controllers, communication interfaces between controllers, nor virtualization or slicing of network resources.
  • SDN Datapath: The SDN Datapath is a logical network device that exposes visibility and uncontended control over its advertised forwarding and data processing capabilities. The logical representation may encompass all or a subset of the physical substrate resources. An SDN Datapath comprises a CDPI agent and a set of one or more traffic forwarding engines and zero or more traffic processing functions. These engines and functions may include simple forwarding between the datapath's external interfaces or internal traffic processing or termination functions. One or more SDN Datapaths may be contained in a single (physical) network element—an integrated physical combination of communications resources, managed as a unit. An SDN Datapath may also be defined across multiple physical network elements. This logical definition neither prescribes nor precludes implementation details such as the logical to physical mapping, management of shared physical resources, virtualization or slicing of the SDN Datapath, interoperability with non-SDN networking, nor the data processing functionality, which can include L4-7 functions.
  • SDN Control to Data-Plane Interface (CDPI): The SDN CDPI is the interface defined between an SDN Controller and an SDN Datapath, which provides at least (i) programmatic control of all forwarding operations, (ii) capabilities advertisement, (iii) statistics reporting, and (iv) event notification. One value of SDN lies in the expectation that the CDPI is implemented in in an open, vendor-neutral and interoperable way.
  • SDN Northbound Interfaces (NBI): SDN NBIs are interfaces between SDN Applications and SDN Controllers and typically provide abstract network views and enable direct expression of network behavior and requirements. This may occur at any level of abstraction (latitude) and across different sets of functionality (longitude). One value of SDN lies in the expectation that these interfaces are implemented in an open, vendor-neutral and interoperable way.

SDN deployment models[edit]

Proactive vs Reactive [9][10]
If flows arrive at a switch, a flow table lookup is performed. Depending on the flow table implementation this is done in a software flow table if a vSwitch is used or in an ASIC if it's implemented in hardware. In the case when no matching flow is found a request to the controller for further instructions is sent. In reactive mode the controller acts after these requests and creates and installs a rule in the flow table for the corresponding packet if necessary. In proactive mode the controller populates flow table entries for all possible traffic matches possible for this switch in advance. This mode can be compared with typical routing table entries today, where all static entries are installed ahead in time. Following this no request is sent to the controller since all incoming flows will find a matching entry. A major advantage in proactive mode is that all packets are forwarded in line rate (considering all flow table entries in TCAM) and no delay is added.
In addition there exists a hybrid mode that follows the flexibility of a reactive mode for a set of traffic and the low-latency forwarding (proactive mode) for the rest of the traffic.

Applications[edit]

One application of SDN is the infrastructure as a service (IaaS).

This extension means that SDN virtual networking combined with virtual compute (VMs) and virtual storage can emulate elastic resource allocation as if each such enterprise application was written like a Google or Facebook application. In the vast majority of these applications resource allocation is statically mapped in inter process communication (IPC). However if such mapping can be expanded or reduced to large (many cores) or small VMs the behavior would be much like one of the purpose built large Internet applications.

Other uses in the consolidated data-center include consolidation of spare capacity stranded in static partition of racks to pods. Pooling these spare capacities results in significant reduction of computing resources. Pooling the active resources increases average utilization.

The use of SDN distributed and global edge control also includes the ability to balance load on lots of links leading from the racks to the switching spine of the data-center. Without SDN this task is done using traditional link-state updates that update all locations upon change in any location. Distributed global SDN measurements may extend the cap on the scale of physical clusters. Other data-center uses being listed are distributed application load balancing, distributed fire-walls, and similar adaptations to original networking functions that arise from dynamic, any location or rack allocation of compute resources.

Other uses of SDN in enterprise or carrier managed network services (MNS) address the traditional and geo-distributed campus network. These environments were always challenged by the complexities of additions, changes, mergers, acquisitions, and movement of users. Based on SDN principles, it is expected that these identity and policy management challenges could be addressed using global definitions decoupled from the physical interfaces of the network infrastructure. On the other hand, existing infrastructure of potentially thousands of switches and routers can remain intact.

It has been noted that this "overlay" approach raises a high likelihood of inefficiency and low performance by ignoring the characteristics of the underlying infrastructure. Hence, carriers have identified the gaps in overlays and asked for them to be filled by SDN solutions that take traffic, topology, and equipment into account.[11]

Security using SDN paradigm

SDN architecture may enable, facilitate or enhance network-related security applications due to the controller’s central view of the network, and its capacity to reprogram the data plane at any time. While security of SDN architecture itself remains an open question that has already been studied a couple of times in the research community,[12][13][14] the following paragraphs only focus on the security applications made possible or revisited using SDN.

Several research works on SDN have already investigated security applications built upon the SDN controller, with different aims in mind. Distributed Denial of Service (DDoS) detection and mitigation,[15][16] as well as botnet [17] and worm propagation,[18] are some concrete use-cases of such applications: basically, the idea consists in periodically collecting network statistics from the forwarding plane of the network in a standardized manner (e.g. using Openflow), and then apply classification algorithms on those statistics in order to detect any network anomalies. If an anomaly is detected, the application instructs the controller how to reprogram the data plane in order to mitigate it.

Another kind of security applications leverages the SDN controller by implementing some moving target defense (MTD) algorithms. MTD algorithms are typically used to make any attack on a given system or network more difficult than usual by periodically hiding or changing key properties of that system or network. In traditional networks, implementing MTD algorithms is not a trivial task since it is difficult to build a central authority able of determining - for each part of the system to be protected - which key properties are hid or changed. In an SDN network, such tasks become more straightforward thanks to the centrality of the controller. One application can for example periodically assign virtual IPs to hosts within the network, and the mapping virtual IP/real IP is then performed by the controller.[19] Another application can simulate some fake opened/closed/filtered ports on random hosts in the network in order to add significant noise during reconnaissance phase (e.g. scanning) performed by an attacker.[20]

Additional value regarding security in SDN enabled networks can also be gained using FlowVisor [21] and FlowChecker [22] respectively. The former tries to use a single hardware forwarding plane sharing multiple separated logical networks. Following this approach the same hardware resources can be used for production and development purposes as well as separating monitoring, configuration and internet traffic, where each scenario can have its own logical topology which is called slice. In conjunction with this approach FlowChecker [21] realizes the validation of new OpenFlow rules that are deployed by users using their own slice.

Developing applications for software defined networks requires comprehensive checks of possible programming errors. Since SDN controller applications are mostly deployed in large scale scenarios a programming model checking solution requires scalability. These functionalities are provided among others through NICE [23]

Access control[edit]

Remote access to the control plane is made available to administrators or users of the network, typically with a role-based access control (RBAC) in order to provide security.

See also[edit]

References[edit]

  1. ^ "Software-Defined Networking: The New Norm for Networks". White paper. Open Networking Foundation. April 13, 2012. Retrieved August 22, 2013. 
  2. ^ "System for regulating access to and distributing content in a network". 
  3. ^ "Prof. Scott Shenker - Gentle Introduction to Software-Defined Networking - Technion lecture". YouTube. 2012-06-26. Retrieved 2014-01-23. 
  4. ^ "Interop 2014: Avaya to showcase Automated Campus part of SDN initiative". Info Tech Lead. 26 March 2014. 
  5. ^ "Avaya Software Defined Data Center". Tech Field Day. Feb 2014. Retrieved 25 June 2014. 
  6. ^ http://www.opennetworking.org/sdn-resources/sdn-definition
  7. ^ http://www.opennetworking.org/sdn-resources/sdn-library/whitepapers
  8. ^ http://www.opennetworking.org/images/stories/downloads/sdn-resources/technical-reports/SDN-architecture-overview-1.0.pdf
  9. ^ "OpenFlow: Proactive vs Reactive". NetworkStatic.net. Retrieved 2014-07-01. 
  10. ^ "Reactive, Proactive, Predictive: SDN Models | F5 DevCentral". Devcentral.f5.com. Retrieved 2014-01-23. 
  11. ^ "Google's software-defined/OpenFlow backbone drives WAN links to 100% utilization". Networkworld.com. 2012-06-07. Retrieved 2014-01-23. 
  12. ^ Kreutz, Diego and Ramos, Fernando and Verissimo, Paulo (2013). "Towards secure and dependable software-defined networks". Proceedings of the second ACM SIGCOMM workshop on Hot topics in software defined networking. pp. 50–60. 
  13. ^ Scott-Hayward, Sandra and O'Callaghan, Gemma and Sezer, Sakir (2013). "SDN security: A survey". Future Networks and Services (SDN4FNS), 2013 IEEE SDN for. pp. 1–7. 
  14. ^ Benton, Kevin and Camp, L Jean and Small, Chris (2013). "Openflow vulnerability assessment". Proceedings of the second ACM SIGCOMM workshop on Hot topics in software defined networking. pp. 151–152. 
  15. ^ Giotis, K and Argyropoulos, Christos and Androulidakis, Georgios and Kalogeras, Dimitrios and Maglaris, Vasilis (2014). "Combining OpenFlow and sFlow for an effective and scalable anomaly detection and mitigation mechanism on SDN environments". Computer Networks 62: 122–136. 
  16. ^ Braga, Rodrigo and Mota, Edjard and Passito, Alexandre (2010). "Lightweight DDoS flooding attack detection using NOX/OpenFlow". Local Computer Networks (LCN), 2010 IEEE 35th Conference on. pp. 408–415. 
  17. ^ Feamster, Nick (2010). "Outsourcing home network security". Proceedings of the 2010 ACM SIGCOMM workshop on Home networks. pp. 37–42. 
  18. ^ Jin, Ruofan and Wang, Bing (2013). "Malware detection for mobile devices using software-defined networking". Research and Educational Experiment Workshop (GREE), 2013 Second GENI. 81-88. 
  19. ^ Jafarian, Jafar Haadi and Al-Shaer, Ehab and Duan, Qi (2012). "Openflow random host mutation: transparent moving target defense using software defined networking". Proceedings of the first workshop on Hot topics in software defined networks. pp. 127–132. 
  20. ^ Kampanakis, Panos and Perros, Harry and Beyene, Tsegereda. "SDN-based solutions for Moving Target Defense network protection". Retrieved 23 July 2014. 
  21. ^ a b Sherwood, Rob and Gibb, Glen and Yap, Kok-Kiong and Appenzeller, Guido and Casado, Martin and McKeown, Nick and Parulkar, Guru (2009). "Flowvisor: A network virtualization layer". OpenFlow Switch Consortium, Tech. Rep. 
  22. ^ Al-Shaer, Ehab and Al-Haj, Saeed (2010). "FlowChecker: Configuration analysis and verification of federated OpenFlow infrastructures". Proceedings of the 3rd ACM workshop on Assurable and usable security configuration. pp. 37–44. 
  23. ^ Canini, Marco and Venzano, Daniele and Peresini, Peter and Kostic, Dejan and Rexford, Jennifer and others (2012). "A NICE Way to Test OpenFlow Applications". NSDI. pp. 127–140. 

External links[edit]