A Survey and a Layered Taxonomy of SDN (2)
- 格式:pdf
- 大小:1.11 MB
- 文档页数:26
基于SDN技术的网络质量优化方案研究随着互联网的普及和网络应用的不断发展,网络质量已经成为人们关注的焦点。
像视频会议、在线教育等实时应用的需求日益增加,对网络带宽和延迟要求也越来越高。
如何保证网络的高可用性和高质量成为了一个急需解决的问题。
而基于SDN技术的网络质量优化方案便是当前研究的热点之一。
SDN(软件定义网络)是指将控制平面和数据平面进行分离,使网络管理人员可以通过软件来实现对网络的全局控制。
这种新型的网络架构使得网络可以更加灵活地响应业务需求。
而基于SDN 的网络质量优化方案在此意义下显得特别重要。
下面从以下几个角度来探讨SDN技术在网络质量方面的优化方案:一、网络拓扑结构的优化一个优秀的网络拓扑结构能够提高网络的性能和质量。
而因为SDN架构将网络的控制平面和数据平面分离,它可以更加灵活地进行网络拓扑结构的调整,从而优化网络质量。
比如,在一些有较高流量需求的网络环境下,SDN可以将网络拓扑结构调整为树型或星型,从而更好地满足业务需求。
另外,SDN还可以在网络拓扑结构中加入一些路由器和交换机的备份,以解决意外故障带来的问题。
二、带宽调度和QoS保证基于SDN的网络可以灵活地分配带宽资源,从而更好地满足业务需求。
比如,在视频会议期间需要大量的带宽资源,SDN可以在保证其他业务不受影响的情况下,将额外的带宽优化地分配给视频会议。
此外,通过设置合适的QoS(Quality of Service),可以保证网络上不同的应用之间互相不会干扰,避免了传统网络中的"拥塞崩溃"现象。
三、流量控制与管理SDN可以通过流表来对网络流量进行控制和管理。
通过控制流表,可以实现对网络上数据包的过滤、分类、转发、修改和统计等操作。
对于不同类型的网络流量,可以根据不同的需求加以处理,比如对实时流量进行优先处理,避免延迟和阻塞等情况。
四、安全性和故障恢复安全性和故障恢复也是网络质量的一个重要方面。
基于SDN 的网络可以借助控制平面来进行安全性和故障恢复等操作。
软件定义网络(SDN)中的协议架构与控制平面在当今信息技术快速发展的背景下,软件定义网络(Software-Defined Networking,简称SDN)作为一种新兴的网络架构方式,在网络领域引起了广泛关注。
SDN以其简化网络管理、提高网络灵活性和可编程性的优势,成为了网络技术的热门话题。
协议架构和控制平面是SDN的核心组成部分,它们在整个系统中起着重要的作用。
本文将详细介绍SDN中的协议架构与控制平面,以期为读者提供一个全面的了解。
一、SDN的协议架构SDN的协议架构主要分为三层:应用层、控制层和基础设施层。
1. 应用层:应用层是SDN网络的最高层,负责实现各种网络应用。
在SDN中,应用层通过使用特定的编程接口(API)与控制层进行交互,以实现网络的各种功能和服务。
其中,SDN应用可以根据网络流量情况动态调整路由策略,实现优化网络性能的目的。
2. 控制层:控制层是SDN网络的灵魂所在,它负责网络的管理和控制。
在SDN中,控制层主要由控制器组成,控制器是SDN网络的中央节点,负责协调和管理各个网络设备。
控制器通过分析网络流量和拓扑结构的信息,生成网络的路由表,并将其发送给基础设施层的网络设备。
此外,控制层还提供了对网络的编程接口,以便应用层可以通过控制器控制网络。
3. 基础设施层:基础设施层是SDN网络的底层,由各种网络设备组成,如交换机、路由器等。
基础设施层负责接收控制器发送的路由表信息,并根据路由表进行数据包的转发。
在SDN中,基础设施层的网络设备和控制器的通信通常是通过OpenFlow协议来实现的。
二、SDN的控制平面控制平面是SDN中实现网络控制的关键组成部分,它由控制器和与之相关的协议组成。
1. 控制器:控制器是SDN网络的核心,它负责管理和控制网络设备。
控制器能够通过与基础设施层的网络设备通信,获取网络的拓扑信息和流量统计数据,并根据这些信息生成路由表。
在SDN中,常用的控制器包括OpenDaylight、Floodlight等。
一个SDN网络有三个架构层:物理网络、SDN控制器、SDN应用程序。
物理网络:最底层包含网络中构成所有IT基础设施的基础的物理设备。
我们使用“交换机”这个概念,因为OpenFlow改变了以太网交换机工作的方式。
在本文中,你还可以考虑物理基础设施中的虚拟交换机部分。
SDN控制器:SDN控制器是中间件,由服务器作为整个架构的轴心。
控制器必须和网络中所有物理以及虚拟设备整合。
控制器将物理网络设备从与这些设备协同工作的SDN软件中抽象化出来。
控制器和网络设备之间有高度的整合。
在OpenFlow环境中,控制器将使用OpenFlow协议和NETCONF协议来与交换机对话。
(OpenFlow是发送流数据到交换机的API,而NETCONF是网络设置API。
)SDN应用程序:SDN设计中最具有可视性的层是提供服务(比如交换/网络虚拟化、防火墙和流量均衡器)的应用程序。
(注意,基于OpenFlow的负载均衡器被称为流量均衡器。
它们并不是传统负载均衡器,因为它们不能读取数据包内容)这些应用程序与那些软件运行在专门硬件上的情境中的应用程序基本类似或相同。
网络技术中大部分即将到来的创新将发生在SDN应用程序上。
(1)为什么要搞SDN?因特网存在和发展了几十年。
随着服务类型和规模的急剧增加出现了一些问题。
长期以来通过命令行接口的手动配置阻碍了网络虚拟化的前进,操作费用高,网络刷新慢,容易引入差错。
取消把应用联系到特定网络详情,譬如断开和地址,使物理具体事项的改变无需重写应用和手动配置网络设备的时延和费用,也许是一种思路。
路由是一个大问题。
路由器里面的路由表越来越复杂,分散到各地去路由,既做不到最优的路由,又产生许多重复的计算。
从你的PC到一个网站浏览器,可能要经过20-100路由器或交换机。
如果一个包到来,只知道目的地,但不知道怎么走,那只有交给下一跳。
下一跳要是也不知道呢?这么盲目跳下去,怎么就相信会到达目的地呢?那只能靠相邻路由器经常交换信息。
SDN(软件定义网络)技术解析随着信息技术的飞速发展,软件定义网络(Software-Defined Networking,SDN)作为一种新兴的网络架构,正在受到越来越多企业和组织的关注和应用。
本文将对SDN技术进行详细解析,包括其基本概念、架构原理、应用场景以及未来发展方向等。
一、基本概念SDN是一种基于软件控制的网络架构,与传统的网络架构相比,它的核心思想是将网络控制平面与数据转发平面进行分离。
传统网络中,网络设备(如交换机、路由器)同时具备控制和数据转发功能,网络管理员通过配置这些设备的命令来控制网络。
而在SDN中,控制器负责决策网络数据的转发路径,将这些决策下发到数据平面设备执行。
这种分离使得网络的管理与控制变得集中化,便于对网络进行统一的管理与维护。
二、架构原理SDN架构主要由三个组件组成:应用层、控制层和基础设施层。
应用层包括各种网络应用,如负载均衡、安全防护等;控制层由控制器组成,负责管理和控制网络中的各种设备;基础设施层则是实际的网络设备,包括交换机、路由器等。
在SDN中,应用层通过与控制层进行交互来获得网络管理的能力。
应用程序可以通过SDN控制器的API接口与其进行通信,通过发送和接收消息来实现网络上的各种功能。
控制层是SDN的核心,它负责对网络进行管理与控制。
控制器通过与基础设施层的网络设备进行通信,提供网络的可编程性和可配置性。
控制器可根据网络策略和管理员的需求,动态地调整网络的配置,并将这些配置下发至网络设备,从而实现对网络的控制。
基础设施层是实际的网络设备,包括交换机、路由器等。
这些设备根据控制器下发的指令来转发数据。
三、应用场景SDN技术在各个领域有着广泛的应用场景。
以下列举几个典型的应用场景:1. 数据中心网络:SDN技术可以对复杂的数据中心网络进行灵活统一的管理。
通过集中化的控制,管理员可以根据实际需求对数据中心网络进行动态配置,提高网络的资源利用率和性能。
2. 广域网(WAN)优化:SDN可以通过对网络流量进行实时监测与调整,提高广域网的带宽利用率和传输效率。
《SDN与NFV技术介绍》知识点摘录导读5G时代,核心网云化可以最大化发挥5G的优势中国移动的目标:建设架构可灵活调整、资源可弹性伸缩、流量可全局调度、能力可全面开放的网络。
一、SDN介绍(一)SDN控制器与SDN相关技术1.NFV和SDN的关系NFV:网元,软硬件分离,电信网元以软硬件形式部署在云上SDN:网络,可以控制物理网元和NFV网元,网络集中控制,把策略下发到网元。
2.数据中心分层架构转发层:租户业务流量转发控制层:租户网络打通云操作系统层:虚拟机创建删除应用层:租户逻辑网络管理3.SDN数据中心Overlay网络:重叠网络,底层网络通过VXLAN技术为用户创建的虚拟网络Underlay网络:底层网络4.VXLAN:隧道封装,24位ID解决了VLAN4096个的限制,增加了UDP、IP等封装头。
VTEP:在VXLAN网络中,用于建立VXLAN隧道的断电设备5.openFlow是SDN南向接口之一,用于转发面和控制面之间,对转发设备编程。
SDN控制器把openFlow流表下发到转发设备,报文匹配到流表就相应转发,否则丢弃。
6.EVPN实现VXLAN隧道的自动建立BGP EVPN扩展*5种类型路由type1-5,实现数据中心内部和之间的互访。
7.SDN数据中心控制方式分两种强控方式:openFlow流表+NETCONF协议配置弱控方式:EVPN学习用户间MAC和ARP+NETCONF8.Aero自研的SDN控制器,可与多厂家转发设备对接,实现SDN南向北向解耦。
9.控制器解耦方案(二)IP相关基础知识1.IP路由基础路由:把一个数据包从一个设备发送到不同网络中的另一设备上去,查路由表匹配,否则丢弃。
路由表通过OSPF、BGP、ISIS、RIP等方式学习得到格式:*学来的协议,目的网段、cost值、出接口、下一跳等分类:静态路由和动态路由静态路由:手工配置,用于小规模网络动态路由:设备间协议交互得到,用于大规模网络自治域内动态路由协议:OSPF、ISIS、RIP自治域AS间动态路由协议:BGP链路状态动态路由协议:OSPF、ISIS距离矢量动态路由协议:RAP、BGP2.OSPF生成发现路由自治域AS内划分多个Area,核心叫做Area0,其他的不直连,而是通过Area0连接。
SDN Architecture Overview Version 1.0December 12, 2013DisclaimerTHIS SPECIFICATION IS PROVIDED "AS IS" WITH NO WARR ANTIES WHATSO EVER, INCLUDING AN Y WARR ANTY O F MER CHANTABILITY, NONIN FRIN GEM ENT, FITN ESS FOR ANY PAR TICU LAR PUR POSE, OR ANY WARR ANTY OTHER WISE AR ISING OU T OF ANY PROPOSAL, SPECIFICATION OR SAMP LE.Without limitation, ONF disclaims all liability, including liability for infringement of any proprietary rights, relating to use of information in this specification and to the implementation of this specification, and ONF disclaims all liability for cost of procurement of substitute goods or services, lost profits, loss of use, loss of data or any incidental, consequential, direct, indirect, or special damages, whether under contract, tort, warranty or otherwise, arising in any way out of use or reliance upon this specification or any information herein.No license, express or implied, by estoppel or otherwise, to any Open Networking Foundation or Open Networking Foundation member intellectual property rights is granted herein.Except that a license is hereby granted by ONF to copy and reproduce this specification for internal use only. Contact the Open Networking Foundation at https:// for information on specification licensing through membership agreements.Any marks and brands contained herein are the property of their respective owners.NoteThis document does not claim global authority over terms used in this document and their definition. All the terms are to be considered in relation to the ONFs SDN architecture, void of any claim of applicability outside the ONFs SDN architecture context. However, for the sake of readability and brevity this document does not always prepend the string “ONF” in front of each term.This version of the overview architecture document is intentionally on a high-level and kept simple. Future more detailed versions may and will extend on this architecture. Example extensions include but are not limited to controller federation, slicing/virtualization, hybrid networks and hybrid switch considerations, layer 4-7 considerations, OA&M, security, charging, performance, northbound interface abstraction layers and functional groups, …,CreditsContributors to this document: Stuart Bailey, Deepak Bansal, Linda Dunbar, Dave Hood, Zoltán Lajos Kis, Ben Mack-Crane, Jeff Maguire, Dan Malek, David Meyer, Manuel Paul, Sibylle Schaller, Fabian Schneider, Rob Sherwood, Johann Tonsing, Tina Tsou, Eve Varma1 SDN Architecture OverviewThis document presents the high-level view of the Software-Defined Network (SDN) architecture as seen by the ONF along with key architectural principles of SDN. Precise implementation details allowed within this SDN architecture are provided in more detailed ONF architecture documents. The aim of SDN is to provide open interfaces enabling development of software that can control the connectivity provided by a set of network resources and the flow ofnetwork traffic though them, along with possible inspection and modification of traffic that may be performed in the network. Figure 1 is a graphical representation of the architectural components and their interactions.The original ONF white paper “Software -Defined Networking: The New Norm for Networks”1 shows infrastructure, control and application layers. In this architecture we refer to them as data, control, and application planes. Atbottom, the data plane is comprised of network elements, whose SDN Datapath s expose their capabilities through the Control-Data-Plane Interface (CDPI) Agent . On top, SDN Applications exist in the application plane, andcommunicate their requirements via NorthBound Interface (NBI) Drivers . In the middle, the SDN Controller translates these requirements and exerts low-level control over the SDN Datapaths, while providing relevantinformation up to the SDN Applications. The Management & Admin plane is responsible for setting up the network1 Link to white paper: https:///images/stories/downloads/sdn-resources/white-papers/wp-sdn-newnorm.pdfFigure 1: Overview of Software-Defined Networking Architectureelements, assigning the SDN Datapaths their SDN Controller, and configuring policies defining the scope of control given to the SDN Controller or SDN Application. This SDN network architecture can coexist with a non-SDN network, especially for the purpose of a migration to a fully enabled SDN network.2 Architectural componentsThe following list defines and explains the architectural components in Figure 1. ONF is continuously updating and evolving the terminology, which is tracked in the ONF Glossary project.∙SDN Application (SDN App): SDN Applications are programs that explicitly, directly, and programmatically communicate their network requirements and desired network behavior to the SDNController via NBIs. In addition they may consume an abstracted view of the network for their internaldecision 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 NBI(s) through respective NBI agent(s) (not shown in Figure 1).∙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 SDNApplications 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 CDPI driver.Definition as a logically centralized entity neither prescribes nor precludes implementation details such asthe 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, which exposes visibility and uncontended control over its advertised forwarding and data processing capabilities. The logical representation mayencompass 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 ormore 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 SDNDatapaths 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 multiplephysical 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 forwardingoperations, (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 andinteroperable 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 networkbehavior 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 in an open, vendor-neutral and interoperable way.∙Interface Drivers & Agents: Each interface is implemented by a driver-agent pair, the agent representing the “southern”, bottom, or infrastructure facing side and the driver representing the “northern”, top, orapplication facing side.∙Management & Admin: The Management plane covers static tasks that are better handled outside the application, control and data planes. Examples include business relationship management between provider and client, assigning resources to clients, physical equipment setup, coordinating reachability andcredentials among logical and physical entities, configuring bootstrapping. Each business entity has its own management entities. Communication among management entities is beyond the scope of this SDNarchitecture. One goal of SDN is to subsume many management tasks known from legacy network into the CDPI.3 Key Principles of this SDN ArchitectureWith SDN, the applications can be network aware, as opposed to traditional networks where the network is application aware (or rather, application ambivalent):∙Traditional (i.e. non-SDN) applications only implicitly and indirectly describe their network requirements, typically involving several human processing steps, e.g., to negotiate if there are sufficient resources andpolicy controls to support the application.∙Traditional networks (e.g. the current Internet and its services like web browsing, media streaming) do not offer a (dynamic) way to express the full range of user requirements, for example throughput, delay, delayvariation or availability. Packet headers can encode priority requests, but network providers typically do not trust user traffic markings. Therefore some networks try to infer the users requirements on their own (e.g.through traffic analysis), which may incur additional cost and sometimes leads to misclassification. SDNoffers the ability for a user to fully specify its needs in the context of a trusted relationship that can bemonetized.∙Traditional (i.e. non-SDN) networks do not expose information and network state to the applications using them. Using an SDN approach, SDN Applications can monitor network state and adapt accordingly.The control plane is (1) logically centralized and (2) decoupled from the data plane. The SDN Controller summarizes the network state for applications and translates application requirements to low-level rules.∙This does not imply that the controller is physically centralized. For performance, scalability, and/or reliability reasons, the logically centralized SDN Controller can be distributed so that several physicalcontroller instances cooperate to control the network and serve the applications.∙Control decisions are made on an up-to-date global view of the network state, rather than distributed in isolated behavior at each network hop. With SDN, the control plane acts as a single, logically centralizednetwork operating system in terms of both scheduling and resolving resource conflicts, as well as abstracting away low-level device details, e.g., electrical vs. optical transmission.The SDN Controller has complete control of the SDN Datapaths, subject to the limit of their capabilities, and thus does not have to compete/contend with other control plane elements, which simplifies scheduling and resource allocation. This allows networks to run with complex and precise policies with greater network resource utilization and quality of service guarantees. This occurs through a well-understood common information model (e.g. as the one defined by OpenFlow).。
IEEECOMMUNICATIONSURVEYS&TUTORIALS,VOL.16,NO.4,FOURTHQUARTER20141955ASurveyandaLayeredTaxonomyofSoftware-DefinedNetworkingYosrJarraya,Member,IEEE,TaousMadi,andMouradDebbabi,Member,IEEE
Abstract—Software-definednetworking(SDN)hasrecentlygainedunprecedentedattentionfromindustryandresearchcom-munities,anditseemsunlikelythatthiswillbeattenuatedinthenearfuture.TheideasbroughtbySDN,althoughoftende-scribedasa“revolutionaryparadigmshift”innetworking,arenotcompletelynewsincetheyhavetheirfoundationsinpro-grammablenetworksandcontrol–dataplaneseparationprojects.SDNpromisessimplifiednetworkmanagementbyenablingnet-workautomation,fosteringinnovationthroughprogrammability,anddecreasingCAPEXandOPEXbyreducingcostsandpowerconsumption.Inthispaper,weaimatanalyzingandcategoriz-inganumberofrelevantresearchworkstowardrealizingSDNpromises.WefirstprovideanoverviewonSDNrootsandthendescribethearchitectureunderlyingSDNanditsmaincompo-nents.Thereafter,wepresentexistingSDN-relatedtaxonomiesandproposeataxonomythatclassifiesthereviewedresearchworksandbringsrelevantresearchdirectionsintofocus.WededicatethesecondpartofthispapertostudyingandcomparingthecurrentSDN-relatedresearchinitiativesanddescribethemainissuesthatmayariseduetotheadoptionofSDN.Furthermore,wereviewseveraldomainswheretheuseofSDNshowspromisingresults.Wealsosummarizesomeforeseeablefutureresearchchallenges.
IndexTerms—Software-definednetworking,OpenFlow,pro-grammablenetworks,controller,management,virtualization,flow.
I.INTRODUCTION
FORalongtime,networkingtechnologieshaveevolvedat
alowerpacecomparedtoothercommunicationtechnolo-gies.Networkequipmentssuchasswitchesandroutershavebeentraditionallydevelopedbymanufacturers.Eachvendordesignshisownfirmwareandothersoftwaretooperatetheirownhardwareinaproprietaryandclosedway.Thisslowedtheprogressofinnovationsinnetworkingtechnologiesandcausedanincreaseinmanagementandoperationcostswhenevernewservices,technologiesorhardwareweretobedeployedwithinexistingnetworks.Thearchitectureoftoday’snetworkscon-sistsofthreecorelogicalplanes:Controlplane,dataplane,andmanagementplane.Sofar,networkshardwarehavebeendevelopedwithtightlycoupledcontrolanddataplanes.Thus,traditionalnetworksareknowntobe“insidethebox”paradigm.Thissignificantlyincreasesthecomplexityandcostofnet-ManuscriptreceivedAugust7,2013;revisedJanuary18,2014;acceptedApril3,2014.DateofpublicationApril24,2014;dateofcurrentversionNovember18,2014.TheauthorsarewiththeConcordiaInstituteforInformationSys-temsEngineering,ConcordiaUniversity,Montreal,QCH3G2W1,Canada(e-mail:y_jarray@encs.concordia.ca).DigitalObjectIdentifier10.1109/COMST.2014.2320094workadministrationandmanagement.Beingawareoftheselimitations,networkingresearchcommunitiesandindustrialmarketleadershavecollaboratedinordertorethinkthedesignoftraditionalnetworks.Thus,proposalsforanewnetworkingparadigm,namelyprogrammablenetworks[1],haveemerged(e.g.,activenetworks[2]andOpenSignalling(OpenSig)[3]).Recently,Software-DefinedNetworking(SDN)hasgainedpopularityinbothacademiaandindustry.SDNisnotarev-olutionaryproposalbutitisareshapingofearlierproposalsinvestigatedseveralyearsago,mainlyprogrammablenetworksandcontrol–dataplaneseparationprojects[4].Itistheoutcomeofalong-termprocesstriggeredbythedesiretobringnetwork“outofthebox”.TheprincipalendeavorsofSDNaretoseparatethecontrolplanefromthedataplaneandtocentralizenetwork’sintelligenceandstate.SomeoftheSDNpredecessorsthatadvocatecontrol–dataplaneseparationareRoutingControlPlatform(RCP)[5],4D[6],[7],SecureArchitecturefortheNetworkedEnterprise(SANE)[8],andlatelyEthane[9],[10].SDNphilosophyisbasedondissociatingthecontrolfromthenetworkforwardingelements(switchesandrouters),logicallycentralizingnetworkintelligenceandstate(atthecontroller),andabstractingtheunderlyingnetworkinfrastructurefromtheapplications[11].SDNisveryoftenlinkedtotheOpenFlowprotocol.ThelatterisabuildingblockforSDNasitenablescreatingaglobalviewofthenetworkandoffersaconsistent,system-wideprogramminginterfacetocentrallyprogramnet-workdevices.OpenFlowisanopenprotocolthatwasborninacademiaatStanfordUniversityaftertheCleanSlateProject.1In[12],OpenFlowwasproposedforthefirsttimetoenableresearcherstorunexperimentalprotocols[13]inthecampusnetworkstheyuseeveryday.Currently,theOpenNetworkingFoundation(ONF),anon-profitindustryconsortium,isinchargeofactivelysupportingtheadvancementsofSDNandthestandardizationofOpenFlow,whichiscurrentlypublishedunderversion1.4.0[14].Themainobjectiveofthispaperistosurveythelitera-tureonSDNovertheperiod2008–2013toprovideadeepandcomprehensiveunderstandingofthisparadigm,itsrelatedtechnologies,itsdomainsofapplication,aswellasthemainissuesthatneedtobesolvedtowardssustainingitssuccess.DespiteSDN’sjuvenility,wehaveidentifiedalargenumberofscientificpublicationsnotcountingmiscellaneousblogs,magazinearticles,andonlineforums,etc.Tothebestofourknowledge,thispaperisthefirstcomprehensivesurveyontheSDNparadigm.Whilereviewingtheliterature,wefoundfewpaperssurveyingspecifcaspectsofSDN[15]–[17].For