1
A Survey of Software-Defined Networking:Past,Prent,and Future of Programmable Networks
Bruno Astuto A.Nunes,Marc Mendonca,Xuan-Nam Nguyen,Katia Obraczka,and Thierry Turletti
玉米糊的做法
Abstract —The idea of programmable networks has recently re-gained considerable momentum due to the emergence of the Software-Defined Networking (SDN)paradigm.SDN,often referred to as a “radical new idea in networking”,promis to dramatically simplify network management and enable in-novation through network programmability.This paper surveys the state-of-the-art in programmable networks with an emphasis on SDN.We provide a historic perspective of programmable networks from early ideas to recent developments.Then we prent the SDN architecture and the OpenFlow standard in particular,discuss current alternatives for implementation and testing of SDN-bad protocols and rvices,examine current and future SDN applications,and explore promising rearch directions bad on the SDN paradigm.
Index Terms —Software-Defined Networking,programmable networks,survey,data plane,control plane,virtualization.
I.I NTRODUCTION
C
OMPUTER networks are typically built from a large number of network devices such as routers,switches and numerous types of middleboxes (i.e.,devices that manipulate traffic for purpos other than packet forwarding,such as a firewall)with many complex protocols implemented on them.Network operators are responsible for configuring policies to respond to a wide range of network events and applications.They have to manually transform the high level-policies into low-level configuration commands while adapting to changing network conditions.And often they need to accomplish the very complex tasks with access to very limited tools.As a result,network management and performance tuning is quite challenging and thus error-prone.The fact that network devices are usually vertically-integrated black boxes exacerbates the challenge network operators and administrators face.
Another almost unsurmountable challenge network practi-tioners and rearchers face has been referred to as “Internet ossification”.Becau of its huge deployment ba and the fact it is considered part of our society’s critical infrastructure (just like transportation and power grids),the Internet has become extremely difficult to evolve both in terms of its phys-ical infrastructure as well as its protocols and performance.However,as current and emerging Internet applications and rvice
s become increasingly more complex and demanding,it is imperative that the Internet be able to evolve to address the new challenges.
Bruno Astuto A.Nunes,Xuan-Nam Nguyen and Thierry Turletti are with INRIA,France,{bruno.uyen,thierry.turletti }@inria.fr
Marc Mendonca and Katia Obraczka are with UC Santa Cruz,{msm,katia }@soe.ucsc.edu
The idea of “programmable networks”has been propod as a way to facilitate network evolution.In particular,Software Defined Networking (SDN)is a new networking paradigm in which the forwarding hardware is decoupled from con-trol decisions.It promis to dramatically simplify network management and enable innovation and evolution.The main idea is to allow software developers to rely on network resources in the same easy manner as they do on storage and computing resources.In SDN,the network intelligence is logically centralized in software-bad controllers (the control plane),and network devices become simple packet forwarding devices (the data plane)that can be programmed via an open interface (e.g.,ForCES [1],OpenFlow [2],etc).
SDN is currently attracting significant attention from both academia and industry.A group of network operators,r-vice providers,and vendors have recently created the Open Network Foundation [3],an
industrial-driven organization,to promote SDN and standardize the OpenFlow protocol [2].On the academic side,the OpenFlow Network Rearch Center [4]has been created with a focus on SDN rearch.There have also been standardization efforts on SDN at the IETF and IRTF and other standards producing organizations.
The field of software defined networking is quite recent,yet growing at a very fast pace.Still,there are important rearch challenges to be addresd.In this paper,we survey the state-of-the-art in programmable networks by providing a historic perspective of the field and also describing in detail the SDN paradigm and architecture.The paper is organized as follows:in Section II,it begins by describing early efforts focusing on programmable networks.Section III provides an overview of SDN and its architecture.It also describes the OpenFlow protocol.Section IV describes existing platforms for developing and testing SDN solutions including emulation and simulation tools,SDN controller implementations,as well as verification and debugging tools.In Section V,we discuss veral SDN applications in areas such as data centers and wireless networking.Finally,Section VI discuss rearch challenges and future directions.
II.E ARLY P ROGRAMMABLE N ETWORKS
SDN has great potential to change the way networks oper-ate,and OpenFlow in particular has been touted as a “radical new idea in networking”[5].The propod benefits range from centralized control,simplified algorithms,commoditizing network hardware,eliminating middleboxes,to enabling the design and deployment of third-party ‘apps’.
While OpenFlow has received considerable attention from industry,it is worth noting that the idea of programmable
h a l -00825087, v e r s i o n 5 - 19 J a n 201
4
2
networks and decoupled control logic has been around for many years.In this ction,we provide an overview of early programmable networking efforts,precursors to the current SDN paradigm that laid the foundation for many of the ideas we are eing today.
a)Open Signaling:The Open Signaling (OPENSIG)working group began in 1995with a ries of workshops dedicated to “making ATM,Internet and mobile networks more open,extensible,and progr
ammable”[6].They believed that a paration between the communication hardware and control software was necessary but challenging to realize;this is mainly due to vertically integrated switches and routers,who clod nature made the rapid deployment of new network rvices and environments impossible.The core of their proposal was to provide access to the network hardware via open,programmable network interfaces;this would allow the deployment of new rvices through a distributed program-ming environment.
Motivated by the ideas,an IETF working group was created,which led to the specification of the General Switch Management Protocol (GSMP)[7],a general purpo pro-tocol to control a label switch.GSMP allows a controller to establish and relea connections across the switch,add and delete leaves on a multicast connection,manage switch ports,request configuration information,request and delete rervation of switch resources,and request statistics.The working group is officially concluded and the latest standards proposal,GSMPv3,was published in June 2002.
b)Active Networking:Also in the mid 1990s,the Active Networking [8],[9]initiative propod the idea of a network infrastructure that would be programmable for customized rvices.There were two main approaches being considered,namely:(1)ur-programmable switches,with in-band data transfer and out-of-band management channels;and (2)capsules,which were program fragments that could be ca
rried in ur messages;program fragments would then be interpreted and executed by routers.Despite considerable activity it motivated,Active Networking never gathered crit-ical mass and transferred to widespread u and industry deployment,mainly due to practical curity and performance concerns [10].
c)DCAN:Another initiative that took place in the mid 1990s is the Devolved Control of ATM Networks (DCAN)[11].The aim of this project was to design and develop the necessary infrastructure for scalable control and management of ATM networks.The premi is that control and management functions of the many devices (ATM switches in the ca of DCAN)should be decoupled from the devices themlves and delegated to external entities dedicated to that purpo,which is basically the concept behind SDNs.DCAN assumes a minimalist protocol between the manager and the network,in the lines of what happens today in proposals such as OpenFlow.More on the DCAN project can be found at [12].Still in the lines of SDNs and the propod decoupling of control and data plane over ATM networks,amongst others,in the work propod in [13]multiple heterogeneous control architectures are allowed to run simultaneously over single physical ATM network by partitioning the resources of that switch between tho controllers.
d)4D Project:Starting in 2004,the 4D project [14],[15],[16]advocated a clean slate design that empha
sized paration between the routing decision logic and the pro-tocols governing the interaction between network elements.It propod giving the “decision”plane a global view of the network,rviced by a “dismination”and “discovery”plane,for control of a “data”plane for forwarding traffic.The ideas provided direct inspiration for later works such as NOX [17],which propod an “operating system for networks”in the context of an OpenFlow-enabled network.
e)NETCONF:In 2006,the IETF Network Configu-ration Working Group propod NETCONF [18]as a man-agement protocol for modifying the configuration of network devices.The protocol allowed network devices to expo an API through which extensible configuration data could be nt and retrieved.
关于诚信的句子Another management protocol,widely deployed in the past and ud until today,is the SNMP [19].SNMP was propod in the late 80’s and proved to be a very popular network management protocol,which us the Structured Management Interface (SMI)to fetch data contained in the Management Information Ba (MIB).It could be ud as well to change variables in the MIB in order to modify configuration ttings.It later became apparent that in spite of what it was originally intended for,SNMP was not being ud to configure network equipment,but rather as a performance and fault monitoring tool.Moreover,multiple shortcomings were detected in the conception of SNMP,t
he most notable of which was its lack of strong curity.This was addresd in a later version of the protocol.
NETCONF,at the time it was propod by IETF,was en by many as a new approach for network management that would fix the aforementioned shortcomings in SNMP.Although the NETCONF protocol accomplishes the goal of simplifying device (re)configuration and acts as a building block for management,there is no paration between data and control planes.The same can be stated about SNMP.A network with NETCONF should not be regarded as fully programmable as any new functionality would have to be implemented at both the network device and the manager so that any new functionality can be provided;furthermore,it is designed primarily to aid automated configuration and not for enabling direct control of state nor enabling quick deployment of innovative rvices and applications.Nevertheless,both NETCONF and SNMP are uful management tools that may be ud in parallel on hybrid switches supporting other solutions that enable programmable networking.
The NETCONF working group is currently active and the latest propod standard was published in June 2011.
f)Ethane:The immediate predecessor to OpenFlow was the SANE /Ethane project [20],which,in 2006,
defined a new architecture for enterpri networks.Ethane’s focus was on using a centralized controller to manage policy and curity in a network.A notable example is providing identity-bad access control.Similar to SDN,Ethane employed two components:a controller to decide if a packet should be forwarded,and an Ethane switch consisting of a flow table
h a l -00825087, v e r s i o n 5 - 19 J a n 2014制作南瓜灯
3
and a cure channel to the controller.
Ethane laid the foundation for what would become Software-Defined Networking.To put Ethane in the context of today’s SDN paradigm,Ethane’s identity-bad access control would likely be implemented as an application on top of an SDN controller such as NOX [17],Maestro [21],Beacon [22],SNAC [23],Helios [24],etc.
III.S OFTWARE -D EFINED N ETWORKING
A RCHITECTURE
Data communication networks typically consist of end-ur devices,or hosts interconnected by the network infras-tructure.This infrastructure is shared by hosts and employs switching elements such as routers and switches as well as communication links to carry data between hosts.Routers and switches are usually “clod”systems,often with limited-and vendor-specific control interfaces.Therefore,once de-ployed and in production,it is quite difficult for current network infrastructure to evolve;in other words,deploying new versions of existing protocols (e.g.,IPv6),not to mention deploying completely new protocols and rvices is an almost insurmountable obstacle in current networks.The Internet,being a network of networks,is no exception.
As mentioned previously,the so-called Internet “ossifica-tion”[2]is largely attributed to the tight coupli
ng between the data–and control planes which means that decisions about data flowing through the network are made on-board each network element.In this type of environment,the deployment of new network applications or functionality is decidedly non-trivial,as they would need to be implemented directly into the infrastructure.Even straightforward tasks such as config-uration or policy enforcement may require a good amount of effort due to the lack of a common control interface to the various network devices.Alternatively,workarounds such as using “middleboxes”(e.g.,firewalls,Intrusion Detection Systems,Network Address Translators,etc.)overlayed atop the underlying network infrastructure have been propod and deployed as a way to circumvent the network ossification effect.Content Delivery Networks (CDNs)[25]are a good example.
Software-Defined Networking was developed to facilitate innovation and enable simple programmatic control of the network data-path.As visualized in Figure 1,the paration of the forwarding hardware from the control logic allows easier deployment of new protocols and applications,straightforward network visualization and management,and consolidation of various middleboxes into software control.Instead of enforc-ing policies and running protocols on a convolution of scat-tered devices,the network is reduced to “simple”forwarding hardware and the decision-making network controller(s).A.Current SDN Architectures
In this ction,we review two well-known SDN architec-tures,namely ForCES [1]and Openflow [2].Both OpenFlow and ForCES follow the basic SDN principle of paration between the control and data planes;and both standardize information exchange between planes.However,they
are
Fig.1.The SDN architecture decouples control logic from the forwarding hardware,and enables the consolidation of middleboxes,simpler policy management,and new functionalities.The solid lines define the data-plane links and the dashed lines the control-plane links.
technically very different in terms of design,architecture,forwarding model,and protocol interface.
1)ForCES:The approach propod by the IETF ForCES (Forwarding and Control Element Separation)Working Group,redefines the network device’s internal architecture having the control element parated from the forwarding element.However,the network device is still reprented as a single entity.The driving u ca provided by the working group considers the desire to combine new forwarding hardware with third-party control within a single network device.Thus,the control and data planes are kept within clo proximity (e.g.,same box or room).In contrast,the control plane is ripped entirely from the network device in “OpenFlow-like”SDN systems.
ForCES defines two logic entities called the Forwarding Element (FE)and the Control Element (CE),both of which implement the ForCES protocol to communicate.The FE is responsible for using the underlying hardware to provide per-packet handling.The CE executes control and signaling functions and employs the ForCES protocol to instruct FEs on how to handle packets.The protocol works bad on a master-slave model,where FEs are slaves and CEs are masters.
An important building block of the ForCES architecture is the LFB (Logical Function Block).The LFB is a well-defined functional block residing on the FEs that is controlled by CEs via the ForCES protocol.The LFB enables the CEs to control the FEs’configuration and how FEs process packets.
谦逊的近义词ForCES has been undergoing standardization since 2003,and the working group has published a variety of documents including:an applicability statement,an architectural frame-work defining the entities and their interactions,a modeling language defining the logical functions within a forwarding element,and the protocol for communication between the control and forwarding elements within a network element.The working group is currently active.
h a l -00825087, v e r s i o n 5 - 19 J a n 2014
4
Fig.2.Communication between the controller and the forwarding devices happens via OpenFlow protocol.The flow tables are compod by matching rules,actions to be taken when the flow matches the rules,and counters for collecting flow statistics.
2)OpenFlow:Driven by the SDN principle of decoupling the control and data forwarding planes,OpenFlow [2],like ForCES,standardizes information exchange between the two planes.
In the OpenFlow architecture,illustrated in Figure 2,the forwarding device,or OpenFlow switch,contains one or more flow tables and an abstraction layer that curely communi-cates with a
controller via OpenFlow protocol.Flow tables consist of flow entries,each of which determines how packets belonging to a flow will be procesd and forwarded.Flow entries typically consist of:(1)match fields ,or matching rules,ud to match incoming packets;match fields may contain information found in the packet header,ingress port,and metadata;(2)counters ,ud to collect statistics for the particular flow,such as number of received packets,number of bytes and duration of the flow;and (3)a t of instructions ,or actions ,to be applied upon a match;they dictate how to handle matching packets.
Upon a packet arrival at an OpenFlow switch,packet header fields are extracted and matched against the matching fields portion of the flow table entries.If a matching entry is found,the switch applies the appropriate t of instructions,or actions,associated with the matched flow entry.If the flow table look-up procedure does not result on a match,the action taken by the switch will depend on the instructions defined by the table-miss flow entry.Every flow table must contain a table-miss entry in order to handle table miss.This particular entry specifies a t of actions to be performed when no match is found for an incoming packet,such as dropping the packet,continue the matching process on the next flow table,or forward the packet to the controller over the OpenFlow channel.It is worth noting that from version 1.1OpenFlow supports multiple tables and pipeline processing.Anothe种花赚钱
武汉宜家营业时间r possibility,in the ca of hybrid switches ,i.e.,switches that have both OpenFlow–and non-OpenFlow ports,is to forward non-matching packets using regular IP forwarding schemes.The communication between controller and switch happens via OpenFlow protocol,which defines a t of messages that
can be exchanged between the entities over a cure channel.Using the OpenFlow protocol a remote controller can,for example,add,update,or delete flow entries from the switch’s flow tables.That can happen reactively (in respon to a packet arrival)or proactively .
3)Discussion:In [26],the similarities and differences between ForCES and OpenFlow are discusd.Among the differences,they highlight the fact that the forwarding model ud by ForCES relies on the Logical Function Blocks (LFBs),while OpenFlow us flow tables.They point out that in OpenFlow actions associated with a flow can be combined to provide greater control and flexibility for the purpos of network management,administration,and development.In ForCES the combination of different LFBs can also be ud to achieve the same goal.
We should also re-iterate that ForCES does not follow the same SDN model underpinning OpenFlow,but can be ud to achieve the same goals and implement similar functional-ity [26].幼儿加减法
The strong support from industry,rearch,and academia that the Open Networking Foundation (ONF)and its SDN proposal,OpenFlow,has been able to gather is quite impres-sive.The resulting critical mass from the different ctors has produced a significant number of deliverables in the form of rearch papers,reference software implementations,and even hardware.So much so that some argue that OpenFlow’s SDN architecture is the current SDN de-facto standard.In line with this trend,the remainder of this ction focus on OpenFlow’s SDN model.More specifically,we will describe the different components of the SDN architecture,namely:the switch,the controller,and the interfaces prent on the controller for communication with forwarding devices (south-bound communication)and network applications (northbound communication).Section IV also has an OpenFlow focus as it describes existing platforms for SDN development and testing,including emulation and simulation tools,SDN controller im-plementations,as well as verification and debugging tools.Our discussion of future SDN applications and rearch directions is more general and is SDN architecture agnostic.
B.Forwarding Devices
The underlaying network infrastructure may involve a num-ber of different physical network equipment,or forwarding devices such as routers,switches,virtual switches,wireless access points,to
name a few.In a software-defined network,such devices are often reprented as basic forwarding hard-ware accessible via an open interface at an abstraction layer,as the control logic and algorithms are off-loaded to a controller.Such forwarding devices are commonly referred to,in SDN terminology,simply as “switches”,as illustrated in Figure 3.In an OpenFlow network,switches come in two vari-eties:pure and hybrid.Pure OpenFlow switches have no legacy features or on-board control,and completely rely on a controller for forwarding decisions.Hybrid switches support OpenFlow in addition to traditional operation and protocols.Most commercial switches available today are hybrids.
h a l -00825087, v e r s i o n 5 - 19 J a n 2014
5
1)Processing Forwarding Rules:Flow-bad SDN archi-tectures such as OpenFlow may utilize additional forwarding table entries,buffer space,and statistical counters that are difficult to implement in traditional ASIC switches.Some recent proposals [27],[28]have advocated adding a general-purpo CPU,either on-switch or nearby,that may be ud to supplement or take over certain functions and reduce the complexity of the ASIC design.This would have the added benefit of allowing greater flexibility for on-switch processing as some aspects would be software-defined.
In [29],network processor bad acceleration cards were ud to perform OpenFlow switching.They propod and described the design options and reported results that showed a 20%reduction on packet delay.In [30],an architectural design to improve look-up performance of OpenFlow switching in Linux was propod.Preliminary results reported showed a packet switching throughput increa of up to 25%com-pared to the throughput of regular software-bad OpenFlow switching.Another study on data-plane performance over Linux bad Openflow switching was prented in [31],which compared OpenFlow switching,layer-2Ethernet switching and layer-3IP routing performance.Fairness,forwarding throughput and packet latency in diver load conditions were analyzed.In [32],a basic model for the forwarding speed and blocking probability of an OpenFlow switch was derived,while the parameters for the model were drawn from mea-surements of switching times of current OpenFlow hardware,combined with an OpenFlow controller.
安徽宏村
2)Installing Forwarding Rules:Another issue regarding the scalability of an OpenFlow network is memory limitation in forwarding devices.OpenFlow rules are more complex than forwarding rules in traditional IP routers.They support more flexible matchings and matching fields and also differ-ent actions to be taken upon packet arrival.A commodity switch normally supports between a few thousand up to tens of thousands forwarding rules [33].Also,Ternary Content-Addressable Memory (TCAM)has been ud to support forwarding rules,which can be expensive and power-hungry.Therefore,the rule space is a bottleneck to the scalability of OpenFlow,and the optimal u of the rule space to rve a scaling number of flow entries while respecting network policies and constraints is a challenging and important topic.Some proposals address memory limitations in OpenFlow switches.Devoflow [34]is an extension to OpenFlow for high-performance networks.It handles mice flows (i.e.short flows)at the OpenFlow switch and only invokes the controller in order to handle elephant flows (i.e larger flows).The per-formance evaluation conducted in [34]showed that Devoflow us 10to 53times less flow table space.In DIFANE [35],“ingress”switches redirect packets to “authority”switches that store all the forwarding rules while ingress switches cache flow table rules for future u.The controller is responsible for partitioning rules over authority switches.
Palette [36]and One Big Switch [37]address the rule placement problem.Their goal is to minimize the
number of rules that need to be installed in forwarding devices and u end-to-end policies and routing policies as input to a rule placement optimizer.End-to-end policies consist of a t of
Fig.3.The parated control logic can be viewed as a network operating system,upon which applications can be built to “program”the network.
prioritized rules dictating,for example,access control and load balancing,while viewing the whole network as a single virtual switch.Routing policies,on the other hand,dictate through what paths traffic should flow in the network.The main idea in Palette is to partition end-to-end policies into sub tables and then distribute them over the switches.Their algorithm consists of two steps:determine the number k of tables needed and then partition the rules t over k tables.One Big Switch,on the other hand,solves the rule placement problem parately for each path,choosing the paths bad on network metrics (e.g.latency,congestion and bandwidth),and then combining the result to reach a global solution.C.The Controller
The decoupled system has been compared to an operating system [17],in which the controller provides a programmatic interface to the network.That can be ud to implement management tasks and offer new functionalities.A layered view of this model is illustrated in Figure 3.This abstraction as
sumes the control is centralized and applications are written as if the network is a single system.It enables the SDN model to be applied over a wide range of applications and heterogeneous network technologies and physical media such as wireless (e.g.802.11and 802.16),wired (e.g.Ethernet)and optical networks.
As a practical example of the layering abstraction accessible through open application programming interfaces (APIs),Fig-ure 4illustrates the architecture of an SDN controller bad on the OpenFlow protocol.This specific controller is a fork of the Beacon controller [22]called Floodlight [38].In this figure it is possible to obrve the paration between the controller and the application layers.Applications can be written in Java and can interact with the built-in controller modules via a JA V A API.Other applications can be written in different languages
h a l -00825087, v e r s i o n 5 - 19 J a n 2014
