The future of networking and the past of protocols

[Verwijderd]

Hoi, hallo.

Kan iemand mij wellicht helpen met het volgende: Er is een hele mooie lezing van Scott Shenker op youtube omtrent Software Defined Networking. Kijkt u: YouTube: The Future of Networking, and the Past of Protocols - Scott Shenker

Wat ik nu even niet begrijp, kijkt filmpje 2:20. Hij zegt hier: "If you look at the other fields in the "system" they teach basic principles. In networking we teach a big bag of protocols. We dont have any principles."

Kan iemand mij nu uitleggen wat het verschil is tussen principles and protocols? Als je de definities opzoekt:

Protocols:
Computers. a set of rules governing the format of messages that are exchanged between computers.

Principles:
a rule or law

Ik probeer het verschil tussen de twee op papier te zetten maar.. ik kom er gewoon niet uit. Iemand die hierbij kan helpen? Bij de andere velden van computing leren ze principles, dit zorgt voor innovatie, etc. Bij Networking leren we protocols, het nadeel hiervan is....

Alvast dank.

[CyBeR]

Algemene ideeën versus praktische implementaties.

[Verwijderd]

Slechts een protocol is een standaard v.w.b. sets regels. Waar tegen een principe louter enkele regel aan gaat.

[ Voor 48% gewijzigd door Verwijderd op 22-08-2016 16:00 ]

[Kabouterplop01]

Je zou het ook kunnen lezen als dat de afgesproken standaarden (protocollen) overeenkomende functies (principes) hebben.
Het nadeel zou kunnen zijn dat je heel diep in de protocollen moet duiken om echt te begrijpen wat er gebeurt en wat het betekent. v.s. Als je de principes gebruikt dan snap je sneller het grote plaatje.

[Equator]

Een principe is een grondbeginsel. Een (behoorlijk) vasstaand manier van werken waar slechts in uiterste noodzaak vanaf kan worden geweken.

Omgezet naar hedendaagse invulling: Het principe van het minste privileges. Dit principe dicteert dat een gebruiker in een authorisatiesysteem slechts de benodigde permissies en rechten krijgt die hij / zij nodig heeft om het werk te doen.

Een protocol is een afspraak over de manier waarop een doel wordt bereikt. Het omschrijft alle stappen van a-z. Een protocol kan vastgesteld zijn, of ruimte houden voor enige afwijkingen.

Voorbeeld van een protocol is bijvoorbeeld de manier waarop de kroonprins straks wordt gekroond. Alle stappen om te komen tot dat einddoel zijn reeds beschreven en daar wordt niet van afgeweken. Maar de koning kan wel nog fijn besluiten dat hij even een paar handen schudt met het gewone volk terwijl dit niet afgesproken was.
In computer terminology is een protocol eerder een afgesproken taal waarin gesproken wordt tussen twee of meerdere systemen. We spreken allemaal 'engels' anders verstaan we elkaar niet. Alleen zijn de talen in de IT meer IP/NetBIOS/IPX/HTTP/..etc.

[WhizzCat]

Ik denk dat hij bedoelt dat er qua networking eigenlijk weinig tot geen principes mee spelen. Je netwerk bouw je op zoals jij dat wil en zoals, Cyber al zegt, wat praktisch is. Iets waar je geen principes nodig voor hebt, maar wel moet weten hoe je je protocollen moet implementeren en onderhouden (multicast, unicast, broadcast etc.).

Er is "dit is het best netwerk-principe" terwijl er voor de meeste andere zaken erg veel best practices zijn. Bv. een AD in richten of een VMWare cluster

[Bl@ckbird]

In networking heb je het data plane en het control plane. Denk daarbij aan een modulaire switch. Hierin zit één of twee supervisors en lijnkaarten met switchpoorten. In de lijnkaarten zitten ASICs die packets forwarden. Op de supervisor draait het besturingssysteem van de switch en hier zit de intelligentie om alles aan te sturen. (Zoals routing protocollen als OSPF, BGP, etc.)

Voor het data plane hebben we het OSI model. (Laag 1 t/m 7) Het is een framework waardoor verschillende fabrikanten hardware kunnen maken die compatibel met elkaar is. Elke laag heeft z'n eigen functie. (Fysieke kabels, local switching, flow control, etc.) Het TCP/IP model neemt combineert een aantal lagen van het OSI model, maar ook dit is een framework.

Wat betreft het control plane is het een allegaartje van protocollen. We hebben een loop in het netwerk. Ok.. Laten we Spanning Tree uitvinden. Wanneer er een loop optreed convergeert de netwerk topologie niet snel genoeg. Ok.. Laten we Rapid Spanning Tree uitvinden. Kortom: Het is een lappendeken van protocollen om data betrouwbaar van A naar B te krijgen, maar het zijn telkens snelle fixes. Er zit geen overkoepelende gedachte achter.

SDN gaat dit veranderen. SDN is flow gebaseerd. Traffic flows gaan van A naar B. Software stuurt dit centraal en stuurt de hardware aan. Bij SDN zijn control plane en data plane gescheiden. In een traditioneel netwerk draaide elke router OSPF bijvoorbeeld. En onderling vochten routers uit hoe een data flow door het nietwerk moest lopen. Bij SDN wordt dit centraal door software bepaalt.

Laatst heb ik hierover een sessie over gevolgd van Cisco en zij zien 4 modellen. Het traditionele model waarbij elk netwerkdevice control plane en data plane heeft.

Daarnaast werkt Cisco aan SDN controllers. Met de controller kan je centraal defineren hoe traffic flows door het netwerk moeten lopen. Netwerk apparaten worden aangestuurd door de controller en forwarden data alleen. Tussen de controller en het netwerk apparaat wordt Openflow gepraat, maar dit kan ook een vendor specifiek protocol / API zijn. De controller kan zelf ook aangestuurd worden via een API. In de industrie wordt Openflow als standaard gezien voor South-bound verkeer gezien, tussen netwerk apparaat en controller. Voor North-bound verkeer (controller en 3rd party software) is er ook een API. Maar hier is geen overeenstemming over en elke vendor kan hier zelf iets voor implementeren.

Je kan ook SDN doen zonder een controller. Momenteel stelt Cisco de OnePK API beschikbaar. Steeds meer Cisco apparaten gaan deze API ondersteunen. 3rd Party software kan hiermee direct netwerkapparatuur aansturen, zonder tussenkomst kan een controller.

Daarnaast is er een hybride model. Traditionele technieken worden hierbij gecombineerd met SDN. Binnen Universiteiten is een toepassing om met SDN het netwerk te virtualiseren in slices. Je kan een slice gebruiken om productie traffic te transporteren. Routing gebeurt tradionele via bekende technieken als Rapid Spanning Tree en OSPF. Een andere slice kan men gebruiken om met SDN nieuwe routing technieken te ontwikkelen.

SDN introduceert namelijk behoorlijk grote risico's in het netwerk. Iedereen weet hoe je zaken als Spanning Tree, OSPF en BGP configureert en troubleshoot. Bij SDN kan het gebeuren dat als een programmeur iets verkeerd programmeert, dit van invloed is op het hele netwerk. Routing kan je bijvoorbeeld via SDN doen, maar andere zaken zoals authenticatie van users via traditionele methodes.

Met SDN kan je flows statisch configureren en het netwerk monitoren. Je kan ook naar een model waarbij je het netwerk monitord en dit als input gebruikt om het netwerk bij te sturen. Je kan flows door je netwerk laten stromen en dit aanpassen op dingen als latency, beschikbare bandbreedte en beschikbaarheid. Dit kan nu ook al met bijvoorbeeld routing protocollen, maar dit zijn statische waarden en passen zich niet automatisch aan, aan een andere werkelijkheid. (Een netwerkadmin moet een wijziging doorvoeren.)

Je kan bijvoorbeeld ook denken aan integratie met ERP software. In de ERP software wordt bijvoorbeeld bijgehouden wat de kosten van een verbinding of datacenter zijn. (Variaties in energiekosten kunnen dit bijvoorbeeld bepalen.) De ERP software kan je integreren met een SDN controller, die op zijn beurt de hardware aanstuurt. Heb je zelf een applicatie geschreven als middle-ware, dan kan je OnePK gebruiken om de koppeling te maken tussen je eigen software en de netwerk hardware.

[knutsel smurf]

Allereerst dien je jezelf af te vragen wat waarom SDN of Application Fluent Networking eigenlijk bedacht is.
Het is bedacht omdat er met virtualisatie een grote verandering plaats vind. En die verandering zorgt ervoor dat er ineens veel meer configuratie gedaan dient te worden op laag2.

Denk maar eens aan een grote Host die 25 VM's heeft met één Hypervisor en 2x 10Gbit interfaces. Elke VM heeft zijn eigen virtual NIC en uiteindelijk gaat de data naar de switch via maar 2 kabels. De switch moet dan goed geconfigureerd zijn voor alle VLANS die de ene host heeft. Hierbij moet je er niet aan denken dat je voor elke move van een VM of een actievatie ervan je per switch poort alles moet gaan instellen.

SDN is vooral bedacht om deze configurational nightmare op te lossen, en tegelijkertijd de performance te waarborgen.

Wat nu veel meer een probleem aan het worden is is de link security en de bij behorende performance. Ga je tussen de verschillende hosts VM's verschuiven of activeren wil je dus niet dat je performance onderuit gaat. hierbij komt naar voren dat je dus eigenlijk 1 hele grote switch wilt hebben of een techniek om dit mogelijk te maken.

Gebruik je dus SDN met een controller over je virtual chassis kan je het jezelf dus makkelijk maken, je definieerd 1x welke app's en VM's wat nodig hebben en het netwerk vogelt vanzelf uit wat welke server nodig heeft. Verplaats je of activeer je een nieuwe VM wordt automatisch de switch port geconfigureerd met de settings die het nodig heeft. Shortest Path Bridging zorgt dan dat binnen 1 en het zelfde virtual chassis alle informatie goed wordt verstuurd.

[knutsel smurf]

Voor de gene die het interessant vinden vandaag is er een Webinar omtrent SDN.

http://www3.alcatel-lucen...02820.xml&lu_lang_code=en