Soft­ware De­fined Net­work­ing (SDN) Plat­forms:

The Ef­fi­cient Eight

OpenSource For You - - Contents - By: Dr Anand Nay­yar The au­thor works at Grad­u­ate School, Duy Tan Univer­sity, Da Nang, Viet­nam. He loves to work and re­search on open source tech­nolo­gies, sen­sor com­mu­ni­ca­tions, net­work se­cu­rity, In­ter­net of Things, etc. He can be reached at anand­nay­[email protected] d

Soft­ware de­fined net­work­ing (SDN) is an emerg­ing tech­nol­ogy in the field of cloud com­put­ing. It is highly dy­namic, man­age­able, cost-ef­fec­tive and adapt­able, and is well suited to high-band­width, dy­namic ap­pli­ca­tions. Many SDN plat­forms are avail­able—both open source and com­mer­cial. Se­lect­ing a plat­form suit­able to the re­quire­ments of the cus­tomer is a te­dious task. This ar­ti­cle gives an over­view of eight open source SDN plat­forms, so that in­formed de­ci­sions can be made.

Since 2016, soft­ware de­fined net­work­ing (SDN) has con­tin­ued to evolve rapidly and be­come more ma­ture, re­defin­ing cor­po­rate net­work­ing. Re­cently, IDC pub­lished a study which shows that the SDN mar­ket could be val­ued at around US$ 12.5 bil­lion by 2020. Cloud com­put­ing, in ad­di­tion to third party plat­forms, has in­creased the need for SDN, and this need will rise fur­ther con­sid­er­ing the in­crease in net­work­vir­tu­al­i­sa­tion soft­ware, and SDN ap­pli­ca­tions like vir­tu­alised net­works and se­cu­rity ser­vices.

SDN is be­com­ing pop­u­lar be­cause net­works now lag be­hind other ar­eas of in­fra­struc­ture, es­pe­cially in the com­put­ing and stor­age are­nas. Mod­ern ad­vance­ments like vir­tu­al­i­sa­tion, dis­trib­uted ar­chi­tec­tures, Big Data and cloud com­put­ing re­quire net­work­ing that can adapt and be op­ti­mised on­the­fly us­ing cen­tralised in­tel­li­gence. Var­i­ous com­mer­cial and open source SDN plat­forms are avail­able, so se­lect­ing a plat­form as per the re­quire­ments of the cus­tomer is a te­dious task. This ar­ti­cle aims to sim­plify the se­lec­tion task.

In­tro­duc­ing soft­ware de­fined net­work­ing

The Open Net­work­ing Foun­da­tion (ONF) is a non­profit con­sor­tium ded­i­cated to de­sign­ing, de­vel­op­ing, stan­dar­d­is­ing and com­mer­cial­is­ing SDN. Ac­cord­ing to ONF, “Soft­ware de­fined net­work­ing (SDN) is an emerg­ing net­work ar­chi­tec­ture where net­work con­trol is de­cou­pled from for­ward­ing and is di­rectly pro­gram­mable.”

SDN ba­si­cally refers to the abil­ity of soft­ware ap­pli­ca­tions to pro­gram in­di­vid­ual net­work de­vices

dy­nam­i­cally and there­fore con­trol the be­hav­iour of the net­work as a whole. SDN is de­fined by two char­ac­ter­is­tics—the de­cou­pling of the con­trol and the data planes, and pro­gramma­bil­ity on the con­trol plane.

SDN is an emerg­ing net­work­ing par­a­digm that pro­vides a strong base to change the lim­i­ta­tions of the cur­rent net­work in­fra­struc­ture. First, it breaks the ver­ti­cal in­te­gra­tion by sep­a­rat­ing the net­work’s con­trol logic (the con­trol plane) from the un­der­ly­ing routers and switches that for­ward the traf­fic (the data plane). Sec­ond, with the sep­a­ra­tion of the con­trol and data planes, net­work switches be­come sim­ple for­ward­ing de­vices and the con­trol logic is im­ple­mented in a log­i­cally cen­tralised con­troller (or net­work op­er­at­ing sys­tem), sim­pli­fy­ing pol­icy en­force­ment and net­work re­con­fig­u­ra­tion and evo­lu­tion.

The SDN ar­chi­tec­ture

The ar­chi­tec­ture of SDN is highly dy­namic, man­age­able, cost­ef­fec­tive and adapt­able, and hence is well suited to high­band­width, dy­namic ap­pli­ca­tions. SDN ar­chi­tec­tures de­cou­ple net­work con­trol and for­ward­ing func­tions, en­abling the for­mer to be­come di­rectly pro­gram­mable, so all IT in­fra­struc­ture gets ab­stracted from ap­pli­ca­tions and net­work ser­vices.

Char­ac­ter­is­tics of SDN ar­chi­tec­ture

Di­rectly pro­gram­mable: All the net­work con­trol can be pro­grammed di­rectly be­cause it is de­cou­pled from for­ward­ing func­tions.

Ag­ile: Be­cause of ab­stract con­trol, net­work ad­min­is­tra­tors can per­form dy­namic ad­just­ments to the net­work­wide flow of traf­fic to make the de­sired changes.

Cen­tralised man­age­ment: All the net­work man­age­ment is cen­tralised in SDN con­trollers and main­tains a global view of the net­work, which ap­pears to ap­pli­ca­tions and pol­icy en­gines as a sin­gle and log­i­cal switch.

Full con­fig­u­ra­tion via pro­grams: SDN fa­cil­i­tates net­work ad­min­is­tra­tors in con­fig­ur­ing, man­ag­ing, se­cur­ing and op­ti­mis­ing net­work re­sources very ef­fi­ciently through dy­namic and au­to­mated SDN pro­grams.

Based on open stan­dards and free­dom from ven­dors: SDN fa­cil­i­tates sim­ple net­work de­sign and all op­er­a­tions, be­cause the op­er­a­tion in­struc­tions are pro­vided by SDN con­trollers rather than mul­ti­ple, ven­dor­spe­cific de­vices and pro­to­cols.

Com­po­nents of SDN ar­chi­tec­ture

SDN ap­pli­ca­tions: These are the pro­grams that ex­plic­itly, di­rectly and pro­gram­mat­i­cally com­mu­ni­cate their net­work re­quire­ments and de­sired net­work be­hav­iour to the SDN con­troller through the north­bound in­ter­face (NBI).

SDN con­troller: This is a log­i­cal en­tity that re­ceives in­struc­tions or re­quire­ments from the SDN ap­pli­ca­tion layer and re­lays them to the net­work­ing com­po­nents. It con­sists of one or more NBI agents, the SDN con­trol logic and the ‘con­trol to data­plane in­ter­face’ (CDPI) driver. SDN north­bound in­ter­faces (NBI): These are the in­ter­faces be­tween SDN ap­pli­ca­tions and SDN con­trollers. They pro­vide ab­stract net­work views and en­able di­rect ex­pres­sion of net­work be­hav­iour and re­quire­ments.

SDN south­bound in­ter­faces (SBI): This is an OpenFlow pro­to­col spec­i­fi­ca­tion. Its main func­tion is to en­able com­mu­ni­ca­tion be­tween the SDN con­troller and the net­work nodes (phys­i­cal and vir­tual switches and routers) to fa­cil­i­tate the router in dis­cov­er­ing net­work topol­ogy, in defin­ing net­work flows and re­lay­ing re­quests to the north­bound APIs.

SDN data path: This is a log­i­cal net­work de­vice that ex­poses vis­i­bil­ity and un­con­tested con­trol over its ad­ver­tised for­ward­ing and data pro­cess­ing ca­pa­bil­i­ties. It con­sists of the CDPI agent, a set of one or more traf­fic for­ward­ing en­gines, and zero or more traf­fic pro­cess­ing func­tions.

SDN con­trol to data-plane in­ter­face (CDPI): This is the in­ter­face be­tween the SDN con­troller and SDN data path to pro­vide pro­gram­ming con­trol of all for­ward­ing op­er­a­tions, ad­ver­tise­ments, sta­tis­ti­cal re­port­ing and the no­ti­fi­ca­tion of events.

The planes in SDN

SDN spans five dif­fer­ent planes:

For­ward­ing plane

Op­er­a­tional plane

Con­trol plane

Man­age­ment plan

Ap­pli­ca­tion plane

In ad­di­tion to the above, there are two ab­strac­tion lay­ers – the de­vice and re­source ab­strac­tion layer (DAL) and the net­work ser­vice ab­strac­tion layer (NSAL). There are also two in­ter­faces—one to fa­cil­i­tate com­mu­ni­ca­tion be­tween the con­trol plane, the for­ward­ing plane and the man­age­ment plane; and the other be­tween the man­age­ment plane and the op­er­a­tion plane.

Let’s take a closer look at the mul­ti­ple planes of SDN. For­ward­ing plane: This pri­mar­ily per­forms the task of han­dling pack­ets in the data path based on the in­struc­tions re­ceived from the con­trol plane. It is the ter­mi­na­tion point for con­trol­plane ser­vices and ap­pli­ca­tions.

Op­er­a­tional plane: This is re­spon­si­ble for man­ag­ing the op­er­a­tional state of the net­work de­vices, i.e., to ob­serve whether the de­vice is ac­tive/in­ac­tive, the num­ber of ports on the de­vice and the sta­tus of ev­ery port, etc.

It is the ter­mi­na­tion point for the man­age­ment plane’s ser­vices and ap­pli­ca­tions.

Con­trol plane: This per­forms the duty of mak­ing de­ci­sions on how pack­ets should be for­warded by net­work de­vices and fo­cuses on the for­ward­ing plane. It also fine­tunes the for­ward­ing ta­bles in the for­ward­ing plane on the ba­sis of net­work topol­ogy.

Man­age­ment plane: This per­forms the tasks of mon­i­tor­ing, con­fig­ur­ing and main­tain­ing the net­work de­vices. It pri­mar­ily fo­cuses on the op­er­a­tional plane of the de­vice rather than the for­ward­ing plane. It also drafts all the for­ward­ing rules for the net­work de­vices.

Ap­pli­ca­tion plane: All the ap­pli­ca­tions and ser­vices de­fine the ap­pli­ca­tion plane. It con­tains SDN ap­pli­ca­tions for var­i­ous func­tion­al­i­ties such as net­work man­age­ment, pol­icy im­ple­men­ta­tion and se­cu­rity ser­vices.

Open source SDN plat­forms OpenDayLight

The OpenDayLight project is a col­lab­o­ra­tive SDN project ini­tia­tive of the Linux Foun­da­tion. It uses open pro­to­cols to pro­vide cen­tralised, pro­gram­matic con­trol and net­work de­vice mon­i­tor­ing. OpenDayLight sup­ports OpenFlow, as well as other ready­to­in­stall net­work so­lu­tions.

It pro­vides an in­ter­face to net­work ad­min­is­tra­tors to con­nect to net­work de­vices ef­fi­ciently and in­tel­li­gently, for the best net­work per­for­mance.

It can be de­ployed in var­ied net­work en­vi­ron­ments and sup­ports a mod­u­lar con­troller frame­work as well as SDN stan­dards and pro­to­cols. The OpenDayLight con­troller uses open north­bound APIs, which are used by ap­pli­ca­tions, which in turn use the con­troller to col­lect in­for­ma­tion about the net­work and cre­ate the rules for it, and run dif­fer­ent al­go­rithms to con­duct an­a­lyt­ics.

OpenDayLight can be de­ployed on hard­ware and op­er­at­ing sys­tem plat­forms that sup­port Java.


Fa­cil­i­tates ef­fi­cient con­trol of de­vices with stan­dard and open pro­to­cols.

Pro­vides cen­tralised pro­gram­matic con­trol of the phys­i­cal and vir­tual de­vices in the net­work.

Pro­vides higher­level ab­strac­tion with tons of fea­tures to help net­work en­gi­neers cre­ate new ap­pli­ca­tions and to cus­tomise net­work ad­min­is­tra­tion.

Pro­vides proac­tive sup­port for net­work man­age­ment and traf­fic flow.

Of­fi­cial web­site: Lat­est ver­sion: Oxy­gen


OpenCon­trail is a 2.0 li­censed project that pro­vides net­work vir­tu­al­i­sa­tion func­tion­al­ity on OpenS­tack and other orches­tra­tion sys­tems. It pro­vides all the nec­es­sary com­po­nents for net­work vir­tu­al­i­sa­tion like the SDN con­troller, vir­tual router, an­a­lyt­ics engine and north­bound APIs. It in­cludes ex­ten­sive REST APIs to con­fig­ure and gather data for op­er­a­tions and an­a­lyt­ics from the sys­tem.

OpenCon­trail acts as a fun­da­men­tal net­work plat­form for the cloud in­fra­struc­ture.

The fol­low­ing are the com­po­nents of the OpenCon­trail plat­form:

Con­troller: This per­forms func­tions like ac­cept­ing and con­vert­ing or­ches­tra­tor re­quests for VM cre­ation, trans­lat­ing re­quests, and as­sign­ing net­works. The real­time an­a­lyt­ics engine col­lects, stores and analy­ses net­work el­e­ments; in­ter­acts with net­work el­e­ments for VM net­work pro­vi­sion­ing and en­sures up­time. vRouter: This vir­tu­alised rout­ing el­e­ment han­dles lo­calised con­trol plane and for­ward­ing plane work on the com­pute node.

Gate­way: This elim­i­nates the need for a soft­ware gate­way and im­proves scal­a­bil­ity and per­for­mance.


Ser­vice chain­ing: Rout­ing of traf­fic based on pre­de­fined pol­icy rules.

Pro­vides pub­lic IP ad­dresses with­out NAT.

Trunk­ing: Pro­vides sup­port for all ap­pli­ca­tions that

re­quire 802.1q trunk.

Full sup­port for the SCTP (stream con­trol trans­mis­sion pro­to­col).

Pro­vides high avail­abil­ity to the SDN net­work via the al­lowed ad­dress pair fea­ture.

Port health check­ing.

Of­fi­cial web­site: http://www.opencon­ Lat­est ver­sion: 4.0.1

Open Net­work Op­er­at­ing Sys­tem (ONOS)

ONOS is an open source SDN plat­form for ser­vice providers, de­signed and de­vel­oped by ON.Lab. The pri­mary goal is to cre­ate an SDN op­er­at­ing sys­tem that en­ables com­mu­ni­ca­tions ser­vice providers to pro­vide scal­a­bil­ity, ef­fi­cient per­for­mance and high avail­abil­ity.

It is de­signed for build­ing next­gen­er­a­tion SDN/NFV so­lu­tions, and pro­vides the flex­i­bil­ity to cre­ate and de­ploy new dy­namic net­work ser­vices with a sim­ple pro­gram­ming in­ter­face. It sup­ports both con­fig­u­ra­tion and real­time con­trol of the net­work, elim­i­nat­ing the need to run rout­ing and switch­ing con­trol pro­to­cols in­side the net­work fab­ric.

The plat­form pro­vides ap­pli­ca­tions with a num­ber of high­level ab­strac­tions, through which the ap­pli­ca­tions can learn about the state of the net­work and through which it can con­trol the flow of traf­fic through the net­work. The net­work graph ab­strac­tion pro­vides in­for­ma­tion about the struc­ture and topol­ogy of the net­work. The flow ob­jec­tive is a de­vice­cen­tric ab­strac­tion that al­lows ap­pli­ca­tions to di­rect the flow of traf­fic through a spe­cific de­vice with­out the need to be aware of the de­vice ta­ble pipe­line.


ONOS can be de­ployed as a ser­vice on a clus­ter of ser­vices, and ONOS soft­ware can run on each server. It makes ONOS highly scal­able and fa­cil­i­tates seam­less ca­pac­ity.

ONOS fea­tures north­bound and south­bound ap­pli­ca­tion pro­gram in­ter­faces (APIs) grounded in ab­strac­tion to pre­vent con­fig­u­ra­tion and pro­to­col lock­in for ap­pli­ca­tions and de­vices, re­spec­tively. ONOS uses its In­tent Frame­work sub­sys­tem that al­lows ap­pli­ca­tions to spec­ify what they need from the sys­tem—if an ap­pli­ca­tion needs more band­width. ONOS Core is dis­trib­uted to pro­vide reach­a­bil­ity to each net­work switch­ing de­vice. The ONOS con­troller re­mains log­i­cally cen­tralised and the sep­a­rate sub­di­vi­sions or in­stances in the com­plete ONOS ar­chi­tec­ture can be viewed and ac­cessed as a sin­gle sys­tem.

Soft­ware mod­u­lar­ity in ONOS means that the com­mu­nity has been dili­gent about keep­ing soft­ware func­tions well de­fined and lo­calised by defin­ing the right ab­strac­tions and in­ter­faces. This has many im­por­tant ben­e­fits, in­clud­ing soft­ware that is eas­ier to read, test and main­tain.

ONOS ab­stracts de­vice char­ac­ter­is­tics so that the core op­er­at­ing sys­tem does not have to be aware of the par­tic­u­lar pro­to­col be­ing used to con­trol or con­fig­ure a de­vice. ONOS has an ex­ten­sive and grow­ing list of south­bound sup­port in­clud­ing P4, OpenFlow, NETCONF, TL1, SNMP, CLI, BGP, RESTCONF and more.

The ONOS YANG tool­chain pro­vides a com­piler ca­pa­ble of pars­ing YANG source files and gen­er­at­ing Java arte­facts, which can be used for writ­ing ap­pli­ca­tions against the ab­strac­tions de­fined by the YANG mod­els. It also pro­vides a run­time ca­pa­ble of en­cod­ing and de­cod­ing be­tween such in­ter­nal mod­els and their ex­ter­nal JSON or XML data rep­re­sen­ta­tions. Other fea­tures in­clude high per­for­mance, re­silience, next­gen de­vice sup­port and le­gacy de­vice sup­port.

Of­fi­cial web­site: https://onospro­

Open vSwitch

Open vSwitch is an open source im­ple­men­ta­tion of the dis­trib­uted vir­tual multi­layer switch, li­censed un­der the open source Apache 2 li­cence. It was orig­i­nally cre­ated by a team at Ni­cira and now it has been ac­quired by VMware. Open vSwitch is de­signed to en­able ef­fec­tive net­work au­to­ma­tion through pro­gram­matic ex­ten­sions, while sup­port­ing stan­dard man­age­ment in­ter­faces and pro­to­cols like NetFlow, sFlow, SPAN, RSPAN, CLI, LACP and 802.1ag.

Tools pro­vided by Open vSwitch ovs­ofctl: For query­ing and con­trol­ling OpenFlow switches and con­trollers. ovs­pki: For cre­at­ing and man­ag­ing pub­lic­key in­fra­struc­ture for OpenFlow switches. ovs­test­con­troller: This is use­ful for test­ing.


IPv6 sup­port: Mul­ti­ple tun­nelling pro­to­cols ­ GRE, VXLAN, STT with IPSec sup­port.

Best QoS; Sup­port for HFSC qdisc; ker­nel and userspace for­ward­ing engine op­tions.

BFD and 802.1ag link mon­i­tor­ing: Stan­dard 802.1Q VLAN model with trunk­ing.

Trans­ac­tional con­fig­u­ra­tion data­base with C and Python bind­ings.

For­ward­ing layer ab­strac­tion to ease point­ing to new soft­ware and hard­ware plat­forms.

Of­fi­cial web­site:­ Lat­est ver­sion: 2.9.0

Open Plat­form for Net­work Func­tions Vi­su­al­i­sa­tion (OPNFV)

Open Plat­form for NFV is a col­lab­o­ra­tive open source plat­form started by the Linux Foun­da­tion in 2014. It fa­cil­i­tates the de­ploy­ment and evo­lu­tion of NFV com­po­nents across var­i­ous open source ecosys­tems.

Via sys­tem level in­te­gra­tion, de­ploy­ment and test­ing, OPNFV cre­ates a ref­er­ence NFV plat­form to ac­cel­er­ate the trans­for­ma­tion of en­ter­prise and ser­vice provider net­works for cre­at­ing an open source plat­form that speeds up the de­vel­op­ment and de­ploy­ment of NFV.

The ob­jec­tives be­hind the de­vel­op­ment of OPNFV are to cre­ate an in­te­grated and ver­i­fied open source plat­form for NFV func­tion­al­ity, pro­vide proac­tive co­op­er­a­tion of end users to val­i­date OPNFV needs, and con­trib­ute to and en­gage in open source projects.


Pro­vides au­to­mated de­ploy­ment tools, ro­bust con­tin­u­ous in­te­gra­tion and global test in­fra­struc­ture. It en­ables de­vel­oper col­lab­o­ra­tion and rapid in­te­gra­tion across the cloud, SDN and cloud ecosys­tems.

Pro­vides a set of sce­nar­ios that ac­cel­er­ate time­tomar­ket for the de­vel­op­ment and de­ploy­ment of NFV. En­sures in­ter­op­er­abil­ity in de­ploy­ment, net­work in­te­gra­tion and VNF ap­pli­ca­tions.

Works in col­lab­o­ra­tion with var­i­ous SDOs like ETSI NFV ISG, IETF, MEF, TM Fo­rum and oth­ers.

Of­fi­cial web­site: Lat­est ver­sion: Euphrates; 5.1

Project Flood­light

Project Flood­light is an SDN open source project sup­ported by Big Switch Net­works and the SDN com­mu­nity. It has been de­signed for easy setup with min­i­mal de­pen­den­cies and to be user friendly for de­vel­op­ers. It of­fers a mod­u­lar sys­tem, mak­ing it sim­ple to en­hance with a fea­ture set. It sup­ports a broad range of hy­per­vi­sor­based vir­tual switches like Open vSwitch.

The Flood­light con­troller has a set of com­mon func­tion­al­i­ties to con­trol and en­quire an OpenFlow net­work, while ap­pli­ca­tions on top of it have dif­fer­ent fea­tures to solve var­i­ous user needs over the net­work.

Flood­light con­troller works with the OpenFlow pro­to­col to or­ches­trate traf­fic flows in an SDN en­vi­ron­ment. OpenFlow is one of the first and most widely used SDN stan­dards; it de­fines the open com­mu­ni­ca­tions pro­to­col in an SDN en­vi­ron­ment that al­lows the SDN con­troller (the brains of the net­work) to speak to the for­ward­ing plane (switches, routers, etc) for mak­ing changes to the net­work.

The SDN con­troller is re­spon­si­ble for main­tain­ing all the net­work rules and pro­vides the nec­es­sary in­struc­tions to the un­der­ly­ing in­fra­struc­ture on how traf­fic should be han­dled. This en­ables busi­nesses to bet­ter adapt to their chang­ing needs and have bet­ter con­trol over their net­works.


Of­fers a mod­ule­load­ing sys­tem that makes it sim­ple to ex­tend and en­hance.

Easy to set up with min­i­mal de­pen­den­cies.

Sup­ports a broad range of vir­tual and phys­i­cal OpenFlow switches.

Can han­dle mixed OpenFlow and non­OpenFlow net­works – it can man­age mul­ti­ple is­lands of OpenFlow hard­ware switches.

De­signed to be high­per­for­mance, it is the core of a com­mer­cial prod­uct from Big Switch Net­works.

Of­fers sup­port for OpenS­tack (link) cloud orches­tra­tion plat­form.

Of­fi­cial web­site:­ject­flood­­light/ Lat­est ver­sion: 1.2


POX is an open source Python­based plat­form for com­mu­ni­cat­ing with SDN switches ei­ther us­ing OpenFlow or the OVSDB pro­to­col. It can func­tion as an OpenFlow con­troller or switch, and can also be used for writ­ing net­work soft­ware. It is a very pop­u­lar tool for re­search­ing SDN and net­work ap­pli­ca­tion pro­gram­ming. The POX con­troller comes pre­in­stalled with the Mininet vir­tual ma­chine. Us­ing the

POX con­troller, sys­tems ad­min­is­tra­tors can con­trol OpenFlow de­vices like the hub, switch, fire­wall, etc.

Dif­fer­ent pa­ram­e­ters can be passed to POX ac­cord­ing to real or ex­per­i­men­tal topolo­gies, thus al­low­ing you to run experiments on real hard­ware, testbeds or in a Mininet em­u­la­tor.


Pro­vides a Pythonic OpenFlow in­ter­face.

Has re­us­able sam­ple com­po­nents for path se­lec­tion, topol­ogy dis­cov­ery, etc.

Fully com­pli­ant and ef­fi­cient to run in any op­er­at­ing sys­tem en­vi­ron­ment, and comes pre­in­stalled with a Mininet sim­u­la­tor.

Sup­ports a graph­i­cal user in­ter­face (GUI) and vir­tual ar­chi­tec­ture sim­i­lar to NOX.

Pro­vides bet­ter per­for­mance as com­pared to NOX writ­ten in Python.

Of­fi­cial web­site: Lat­est ver­sion: 0.2.3


Indigo is an open source project that sup­ports OpenFlow on a wide range of phys­i­cal and non­vir­tual switch plat­forms, and is sup­ported un­der the Apache 2.0 li­cence. It is based on SwitchLight by Big Switch Net­works and is com­posed of the

fol­low­ing com­po­nents.

Indigo Agent: This rep­re­sents the core li­braries and in­cludes a HAL ab­strac­tion layer to fa­cil­i­tate easy in­te­gra­tion with re­gard to for­ward­ing and the port man­age­ment in­ter­faces of phys­i­cal or vir­tual switches. It in­cludes a con­fig­u­ra­tion ab­strac­tion layer to sup­port run­ning OpenFlow in a hy­brid mode.

Lox­iGen: This is a com­piler that gen­er­ates OpenFlow mar­shalling/un­mar­shalling in mul­ti­ple lan­guages.

The ar­chi­tec­ture of Indigo is di­vided into the plat­for­min­de­pen­dent and plat­form­spe­cific cat­e­gories. The plat­for­min­de­pen­dent mod­ules are Socket Man­ager, OpenFlow Con­nec­tion Man­ager and OpenFlow State Man­ager. The con­fig­u­ra­tion plat­form­spe­cific mod­ules are the For­ward­ing and Port Man­ager.


Pure OpenFlow 1.0 im­ple­men­ta­tion.

Cre­ates flex­i­bil­ity in how the net­work is used and op­er­ated as well as for data an­a­lyt­ics.

Easy in­te­gra­tion with com­put­ing for re­search man­age­ment and main­te­nance.

Low­ers op­er­at­ing ex­penses, re­sult­ing in fewer er­rors and less net­work down­time via au­to­mated net­work con­fig­u­ra­tion.

Of­fi­cial web­site:­ject­flood­ Lat­est ver­sion: 2.0


[1]­net­work­­ries/ down­loads/sdn-re­sources/tech­ni­cal-re­ports/SDNar­chi­tec­ture-over­view-1.0.pdf [2] [3] http://www.opencon­ [4] https://onospro­ [5]­ [6] [7]­ject­flood­­light/ [8] [9]­ject­flood­

Fig­ure 1: SDN ar­chi­tec­ture

Fig­ure 2: SDN planes

Newspapers in English

Newspapers from India

© PressReader. All rights reserved.