Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 34, views: 20.201 •

The Linux Foundation heeft samen met achttien bedrijven het OpenDaylight Project opgericht. Onder andere Cisco, IBM, Intel en Microsoft willen met de projectgroep een opensource-platform ontwikkelen voor software-defined networking.

Het OpenDaylight Project bestaat uit Arista Networks, Big Switch Networks, Brocade, Cisco, Citrix, Dell, Ericsson, Fujitsu, HP, IBM, Intel, Juniper Networks, Microsoft, NEC, Nuage Networks, PLUMgrid, Red Hat en VMware. Deze bedrijven willen binnen de door de Linux Foundation opgerichte werkgroep software en andere middelen gaan aanbieden om zo een opensource-platform te ontwikkelen voor software-defined networking. Ook zal gebruik worden gemaakt van open standaarden, zoals het Openflow-protocol. Bovenop het OpenDaylight-platform moeten andere partijen, al dan niet commerciële, sdn-producten kunnen ontwikkelen.

Software-defined networking neemt de laatste jaren een grote vlucht. Met name bedrijven gebruiken de technologie om netwerken binnen datacenters vergaand te virtualiseren. Onder andere Google en Facebook gebruiken sdn-technologie en het Openflow-protocol. Met het OpenDaylight-initiatief zal er onder andere gewerkt worden aan een open netwerkcontroller, een virtual overlay network en diverse plug-ins voor Openflow. De eerste resultaten worden in het derde kwartaal van dit jaar verwacht.

OpenDaylight Project

Reacties (34)

Goed initiatief, open standaarden zijn altijd een goede zaak voor concurrentie en dus voor de consument. Vind het opvallend maar toch ook niet dat Apple hier niet bij betrokken is. Dat ze een chronische allergie hebben voor standaarden die de rest van de wereld aanneemt is bekend, maar dit is toch zeker iets waar ze zelf voordeel uit kunnen halen en alle grote namen bij betrokken zijn.

ben benieuwd ook naar de bedragen waar we over praten. Heeft iemand een bron?

[Reactie gewijzigd door Worsteneter op 8 april 2013 18:01]

Dit is ook niet echt iets dat in Apple's straatje past. Apple is nauwelijks nog actief op de datacenter markt, sinds ze gestopt zijn met de xServe. Ze zijn heel erg consument georienteerd.

Zelf hebben ze natuurlijk wel (enorme) datacenters maar of ze zich daar aan standaarden houden maakt niemand wat uit. Dit gaat meer over het verkopen van apparatuur en software die moet kunnen samenwerken binnen virtuele netwerk omgevingen in datacenters.

[Reactie gewijzigd door GekkePrutser op 8 april 2013 18:08]

Nee daar was ik me van bewust natuurlijk, maar voor eigen datacenters kan het ook zo z'n voordelen hebben.. en die heeft Apple natuurlijk genoeg met iTunes, iCloud en al die diensten ;)

Maar was me gewoon iets wat me op viel tussen al die grote namen in de technologie wereld :)
Apple heeft geen datacenters. iCloud draait op Azure en Amazon.
lol, grapjas. Ik hoop dat je zit te trollen..
Er zijn wel allerlei geruchten over geweest. Hierbij nog een linkje http://www.techzine.nl/ni...n-en-microsoft-azure.html naar een oud artikel hierover.
Leuk artikel!
Serieus waar zo'n groot gebouw om alleen maar concurrentie te imponeren? Dat zou wel erg sick zijn, wauw! Al meer over bekend ondertussen of?
Artikel is 2 jaar oud. Intussen is apple druk bezig met het bouwen van meer en grotere data-centers. Ze zullen toendertijd mischien wat afgehuurd hebben, maar lijkt mij stug dat ze dit nog steeds doen.
Bedragen: http://blogs.wsj.com/cio/...olts-sluggish-sdn-market/

Silver: $10000 - $20000
Gold: $50000 - $250000 + 3 engineers voor 2 jaar, $$ afhankelijk van grootte bedrijf
Platinum: $500000 + 10 engineers voor minimaal 2 jaar
Mmm, voor geinteresseerden: http://www.wired.com/wire...daylight-cisco-microsoft/

('k Vind 't artikel van Wired overigens interessanter geschreven omdat ze met een licht beschuldigende vinger naar de grote bedrijven (Cisco, Juniper & HP) wijzen die cruciale onderdelen voor 't Internet maken, maar jammergenoeg niet zo vernieuwend zijn als 't Internet zelf)
Ja, want eigenlijk is het heel simpel allemaal. Cisco en Juniper houden iedereen voor het lapje. Ze maken het er moeilijker uitzien dan het is.

De realiteit is:
Networking kan heel erg complex zijn.

En om protocollen te implementeren, zodat het ook werkt als je meer dan een speelgoed netwerk hebt, dat is nog niet zo makkelijk. Iedereen kan een router of switch bouwen, en er control-software voor schrijven. Gewoon de prijs iets onder die van de afzetters cisco/Juniper/HP gooien, en je verkoopt je producten als zoete broodjes.

Echter, niemand lukt dat. Control-software schrijven blijkt toch te moeilijk te zijn voor de meesten. Zeker als je niet de ervaring hebt om bij een van de vendors, of een van de hele grote ISPs te werken.

Nu is er SDN. Fantastisch. Alles wordt makkelijker.
Maar niet heus.
Als je niet begrijpt hoe je de technologie voor de netwerken van vandaag moet bouwen, dan weet je zeker niet hoe je technologie voor morgen moet bouwen. Met andere woorden: als SDN een succes wordt, dan loopt de oude garde, van cisco, Juniper, etc, gewoon weer voorop. Misschien dat er 1 of 2 nieuwe spelers komen. Maar de grootste kans is: de hierarchie blijft bij hetzelfde.
Ik ben het eigenlijk niet eens met jouw stellingen. Het is gewoon een kwestie van goede interfaces definiŽren. Of ze dat lukt, dat weet ik niet overigens.

Maar kijk bv naar filesystemen. De hele hardware is vanuit de software niet zichtbaar. Je hebt alleen files en daar kan je naar schrijven, lezen, verwijderen enz.

Dus als er goede interfaces zijn, zou er goed mee te werken moeten zijn.
Dus als er goede interfaces zijn, zou er goed mee te werken moeten zijn.
De huidige netwerk technologie bestaat voor 99% uit goede interfaces. Dat heet "protocollen". De meeste zijn gewoon gratis te downloaden. Zie:
http://en.wikipedia.org/wiki/Request_for_Comments
http://www.ietf.org/rfc.html

Daar zijn er zo'n 6000 van. Alles wat je wilt weten over netwerk technologie staat daar ergens in beschreven. (Nou ja, een hoop. Er zijn ook nog IEEE standarden, ISO/OSI standarden, etc).

Mijn punt is: zelfs als die interfaces (of standaarden, of protcollen) heel goed zijn, en duidelijk zijn, dan is het nog steeds niet makkelijk om ze te implementeren. Dat wil simpelweg zeggen: om programmatuur te schrijven die doet wat ze moet doen.

Ooit een BGP implementatie geschreven ? Werkte het thuis, met 4 routers en 100 prefixes ? Wat denk je als je 100 peers krijgt, met 5 full views van 500000 routes ? Werkt het dan nog ? Als je lijnen staan te klapperen ? Hoe is je memory-fragmenatie nadat je router 3 maanden loopt te draaien, zonder een reboot/restart ?

Ik denk altijd terug met plezier aan dit artikel.
http://www.lightreading.c...e-ip-priesthood/240045076
In 2001 waren er 50 mensen op aarde die wisten hoe je een routing protocol moest schrijven. Misschien dat het er nu een paar honderd zijn. (En die werken of voor cisco en juniper, of ze hebben geen zin meer om weer een BGP te schrijven). Ik denk dat de kennis over control-planes op routers nog steeds erg beperkt is. En er is heel hele hoop meer om te begrijpen dan BGP/IS-IS/OSPF/EIGRP.

En dat zorgt er voor dat het erg moeilijk is om er tussen te komen. Zelfs als je leuke hardware kunt bouwen, dan kun je nog steeds geen goede router of switch bouwen. Daardoor blijft de concurrentie klein.

SDN is een poging om de markt te resetten.
Om de oude giganten buiten spel te zetten.
En nieuwe bedrijven een kans te geven.

De vraag is: gaat dat lukken ?

Ik denk dat dat minder goed gaat lukken dan je op het eerst gezicht denkt.
Het overgrote deel van die 6000 protocollen is reeds tientallen jaren oud, en ontworpen voor de issues die toen speelden. Netwerken zijn alleen maar toegenomen in complexiteit, en dankzij server virtualisatie neemt niet alleen het aantal servers in data centers toe, maar ook de frequentie van configuratie wijzigingen, het aantal klanten die via self-provisioning wijzigingen doorvoert, etc. Hierdoor loop je tegen allerlei limieten aan ( bijvoorbeeld het beperkte aantal VLANs wat je met 12 bits kunt hebben ).

Nou kun je natuurlijk de bestaande protocollen "oprekken" en zodoende het probleem uitstellen. Gevolg is de huidige wildgroei aan alternatieve protocollen en tunnel encapsulaties die ongeveer hetzelfde doen.

SDN is een poging om de fundamentele architectuur van netwerken anders aan te pakken. In combinatie met initiatieven als Network Function Virtualization (NFV) leidt dit tot iets nieuws, en tot een herschikking van vendors. Software schrijven heeft een lagere drempel dan hardware bouwen - al hoewel je nog steeds moet weten wat je doet.
SDN gaat alleen over de control-plane.
Dus hoe je forwarding-entries opstelt. Welk traffic gaat waar ? Voeg je VLANs toe ? Voeg je GRE toe ? Voeg je MPLS toe ?

Voor al die forwarding technieken blijven we dezelfde protocollen gebruiken. IP, MPLS, GRE, VLANs, VXLANs, QinQ, noem maar op. Met dezelfde limieten. Dus daar is SDN niet voor.

Wat veranderd is hoe die VLANs, tunnels, etc tot stand komen.
Vroeger (en nu) deed je dat door routers en switches te configureren. Dan kreeg je (statische) VLANs en tunnels. Of je configureert IGPs (routing protocollen). Die dan forwarding entries in de FIB (forwarding table) plaatsten.

Met SDN moet dat juist anders worden. Minder configuratie op de routers. En meer configuratie op de centrale controller. En je laat IGPs (en STP) minder werk doen, en je laat de controller uitrekenen hoe je traffic moet vloeien door je netwerk.

Als je denkt dat software schrijven makkelijker is, dan weet ik dat nog niet zo zeker. Hardware maken kan duur zijn (zeker als je zelf chips wilt ontwerpen). Hardware samenstellen (koop wat chips van Brocade, een cpu van Intel, etc) is al een hoop makkelijker. En de functionaliteit van forwarding hardware is simpeler dan de functionaliteit van control-plane software.

Maar inderdaad. Als iedereen zelf software kan schrijven om te integreren met een opensource controller, dan zou daar af en toe iets goeds tussen moeten zitten. Ik ben benieuwd.
Leuk, zo'n artikel, maar het zou fijn zijn als het uitlegt wat software-defined networking is.
Volgens wikipedia is het bedoeld om netwerken beheersbaar te maken wanneer er virtual machines gebruikt worden. Ook maakt software-defined networking het mogelijk om het netwerk verkeer te beheren zonder fysiek toegang te hebben tot de netwerkapparatuur.

bron: http://en.wikipedia.org/wiki/Software-defined_networking
De definitie van "SDN" is nog vollop in ontwikkeling, je kunt het deze journalist niet kwalijk nemen. Dit soort projecten helpt SDN te definieren
Hoe gaat dat precies in het straatje passen met quantum? Krijgt quantum (in theorie) dan een OpenDaylight plugin of wordt dat meer een quantum vervanger?
Quantum heeft al een openflow plugin:
https://wiki.openstack.org/wiki/Quantum_NEC_OpenFlow_Plugin

en losse controllers zijn er ook al in soorten en maten:
bv:
http://www.projectfloodlight.org/floodlight/
http://www.noxrepo.org/
maar ook in Lua
http://www.lua.org/wshop12/Amorim.pdf
(deze PDF legt ook mooi uit wat SDN/openflow doet !)

en zelfs op basis van node.js
http://garyberger.net/?p=537

Als je zelf een keer met openflow wilt spelen, het draait gewoon op
openwrt

http://www.openflow.org/w.../OpenFlow_1.0_for_OpenWRT

en een WRT54GL kun je voor een paar tientjes op marktplaats opduikelen ;-)
openflow wordt onder tussen al meer dan twee jaar ofzo in productie omgevingen gebruikt met Citrix Xenserver.. de ganse switching stack is openvswitch en openflow gebaseerd. Het feit dat ook VMWare Nicira heeft gekocht (de primaire ontwikkelaars van openvswitch) illustreert dat dit serieuze technologie is.
Simpele beschrijving van SDN. Ieder netwerkdevice bestaat uit een control plane en een dataplane. De controlplane bepaalt hoe de forwarding van pakketten op de dataplane plaatsvindt. Met SDN wordt dit losgetrokken van elkaar de controlplane kan een andere vendor zijn dan de dataplane. De dataplane wordt dan door de controllersoftware dmv het openflow protocol geconfigureerd. Potentieel heel krachtig en flexibel maar makkelijker wordt het niet.
Voor de genen die zich afvragen wat Openflow is.

Simpel gezegd gaat er normaal gesproken een pakketje je switch in en de switch bepaald vervolgens via zijn interne software wat er mee moet gebeuren. Wil je dat die switch iets anders doet dan normaal zul je dus de control software moeten overschrijven met je eigen software en eventueel de interne hardware van de switch moeten kennen. Iets wat de grote switch fabrikanten natuurlijk niet leuk vinden. Openflow is een soort van API op de switch waardoor zeg maar wanneer het pakketje de switch in komt ipv zelf af te handelen de switch weer aan een externe server gaat vragen, wat moet ik met dit pakketje doen? Zo kan je dus weer je eigen netwerk protocollen maken zonder de switch zijn hardware en software te hoeven kennen of modifyen.
Simpele uitleg, dankje!
Nog simpeler:

OpenFlow is een "forwarding table download protocol".

Met dank aan Ivan Peplnjak.
http://blog.ioshints.info/
Ik had al aardig wat gelezen over OpenFlow. Ik wist niet wat ik er van moest maken. Het zag er uit als een "forwarding table download protocol". Maar ik kon niet geloven dat dat is wat het was. Dankzij Peplnjak weet ik nu dat het inderdaad zo simpel is. :)

Zo ver ik weet zijn er nog steeds geen (grote) productie netwerken die echt OpenFlow gebruiken. Ik moet nog zien hoe het in de praktijk gaat werken. (Ik ben vooral bang voor de scaling impact van de design decision om ieder pakket van een nieuwe flow eerst naar de controller te sturen. Fast-switching all over again).
Het is ook volgens mij meer nog een idee, dan dat er al echt bruikbare toepassingen zijn.
Maar op deze manier werkt Microsoft toch mee aan iets wat hun eigen concurrent wordt?
Ze zijn dan toch patent houder?
Het kont er toch wel dan kunnen ze er beter bij betrokken zijn
Nuage Networks - een nieuwe venture van Alcatel-Lucent - heeft vorige week als een van de eerste vendors een complete SDN oplossing gelanceerd, zie o.a. http://www.fierceenterpri...w-sdn-platform/2013-04-04

(disclaimer: ik werk voor Nuage Networks)
Over SDN zeg ik meestal dat het voor networking is wat cloud voor computing was. Wellicht niet 100% correct maar het dekt de lading wel zo'n beetje.

In allerlei hoeken loopt de ontwikkeling richting standardhardware op general purpose CPU's, servers gaan steeds meer richting x86, gameconsoles gaan richting x86, etc, etc. Ook in de networking, waar veel met purpose built hardware wordt gewerkt zie je nu steeds meer x86 ontstaan. Die performed zeker voor dezelfde taken nog niet hetzelfde als een stuk purpose built hardware maar voor veel doeleinden performed het prima. Daarnaast biedt het de mogelijkheid om hele specifieke oplossingen te knutselen voor specifieke diensten die je wellicht liever niet op je generieke cluster hebt.

Virtuele switches waren er van Cisco al, nu zal je ook o.a. virtuele routers en loadbalancers van ze gaan krijgen en met openflow daarbovenop kan je hele creatieve dingen gaan doen.

Dat al die partijen samenwerken is in ieder geval goed nieuws, dat zal eerder tot generieke standaarden leiden. Ik zie dit niet zo snel leiden tot andere spelers of veranderen van de markt, de partijen die snappen wat je wil doen en hoe je dat implementeert blijven nog steeds hetzelfde. Creatieve oplossingen bouwen die gebruik maken van SDN en/of openflow komt wel binnen bereik van veel meer partijen hiermee, maar in de lagen daaronder zal volgens mij niet dramatisch veel op de markt gaan gebeuren.
Die andere spelers bestaan reeds enkele jaren, zie bijvoorbeeld http://www.midokura.com/ en http://www.6wind.com/. De spelers met vroeg markt succes zoals Nicira zijn reeds opgekocht, maar de grote bestaande bedrijven kunnen concurrentie niet eeuwig blijven wegkopen. Er zullen onherroepelijk nieuwe spelers ontstaan, net zoals in de natuur continu nieuwe soorten ontstaan - maar dan sneller

Op dit item kan niet meer gereageerd worden.