De (lange) weg naar Software Defined Networking

Inmiddels worden de termen “OpenFlow” en “SDN” al een paar jaar geroepen als oplossing voor alle problemen die netwerk operators op dit moment hebben. Het aantal praktische implementaties is echter tot dusver nog maar op één hand te tellen. Hoe komt dat en hoe zorgen we ervoor dat die oplossingen er echt komen?

Door de groei van (de complexiteit van) netwerken en de bijbehorende managementsystemen raken operators steeds meer het overzicht en de controle over hun netwerk kwijt. En die controle hebben ze juist hard nodig om te voldoen aan de groeiende vraag naar nieuwe services die flexibel en snel veel bandbreedte kunnen leveren. Het feit dat Software Defined Networking (SDN) en OpenFlow zoveel aandacht krijgen is dan ook niet gek, samen beloven zij een manier om het netwerk weer onder controle te krijgen. De potentiële toepassingen en applicaties worden dan ook vol lof gepresenteerd op verschillende conferenties, maar daarvan worden er uiteindelijk maar een aantal verwezenlijkt buiten de wetenschappelijke wereld.

Nieuwe diensten

Eerder dit jaar heb ik als afstudeerproject onderzocht hoe een praktische implementatie van SDN en OpenFlow eruit zou zien ten opzichte van een implementatie die gebruikt maakt van huidige technologieën (PDF). Het onderzoek probeert een stap terug te doen van de hele OpenFlow heisa om te zien of door alle focus op SDN, de huidige technologieën niet worden vergeten als alternatief. MPLS doet bijvoorbeeld al vele jaren dienst als een zeer schaalbare technologie voor bijna elk soort provider netwerk. Om deze oude technologie te vergelijken met de nieuwe wijze van Software Defined Networking heb ik gekeken naar het implementeren van dynamische Layer 2 VPNs. Qua technologie zijn statisch geconfigureerde Layer 2 VPNs niet heel geavanceerd. Echter, de vereiste flexibiliteit en behendigheid van het managementsysteem voor het evolueren naar dynamische VPNs is over het algemeen nog ongekend in de netwerkwereld.

Rob Wilts schreef onlangs nog op ISP Today over de potentie van SDN met betrekking tot Bandwidth on Demand (BWoD)-diensten, een dienst die tevens een dynamisch en flexibel managementsysteem vereist. Ook de problemen die hij aandraagt staven de conclusie uit het onderzoek: huidige technologieën als MPLS lopen tegen managementlimieten aan. Door het gebrek aan een standaard management-interface is het schrijven van een flexibel managementsysteem een intensieve taak. Dit wordt nog eens extra bemoeilijkt door de afhankelijkheden die MPLS heeft van de verschillende protocollen die worden gebruikt door de technologie (RSVP, LDP, etc.).

Tekortkomingen

Na deze vergelijkbare constateringen houden de overeenkomsten tussen onze uiteenzettingen echter op. Wilts gaat verder met het aanraden van OpenFlow en SDN voor dergelijke diensten met alle voordelen van dien, maar gaat daarbij voorbij aan de tekortkomingen die deze technologieën op dit moment nog hebben. Software Defined Networking is een manier van netwerken die een dergelijke mate van flexibiliteit mogelijk maakt dat het fantaseren over mogelijke oplossingen oneindig lijkt. Maar SDN bestaat uit meerdere onderdelen die nog niet compleet zijn uitgewerkt: de forwarding plane die het daadwerkelijke switchen/routen voor zich neemt, de centrale controller die de forwarding planes instrueert, en de verschillende interfaces tussen deze twee basale onderdelen.

Op dit moment is OpenFlow de bekendste interface tussen de controller en de forwarding plane, de zogenaamde southbound interface. In OpenFlow is de forwarding plane per definitie ‘dom’; zonder controller kunnen er geen beslissingen worden gemaakt. Dit is ten eerste een probleem voor redundantie mocht de controller uitvallen. Een minder makkelijk op te lossen probleem is de snelheid waarmee er een fail-over kan plaats vinden mocht een fysieke link niet meer werken. Dit probleem stamt uit een grotere zorg die heerst met betrekking tot het centraliseren van het netwerkmanagement: de afzonderlijke apparaten verliezen hierdoor hun autonomie. Hierdoor kan het netwerk minder snel reageren op fouten.

Naast de southbound interface zijn er nog meer interfaces vanaf de controller. De northbound interface bijvoorbeeld zorgt voor de communicatie tussen de controller en de verschillende applicaties die zorgen voor de intelligentie in het netwerk. Deze interface is alleen nog niet gedefinieerd zoals OpenFlow dat al wel is. Dit heeft als gevolg dat de gevreesde vendor lock-in die vermeden wordt door OpenFlow, opnieuw kan plaats vinden door het gebruik van één enkele controller leverancier die alleen met zijn eigen apps kan praten. Ditzelfde geldt voor de east/westbound interface die wordt gebruikt tussen verschillende controllers, zonder een standaard protocol zouden alleen controllers van één en dezelfde leverancier kunnen worden gebruikt. Als deze interfaces niet worden gedefinieerd zal hetzelfde probleem ontstaan dat op dit moment aanwezig is bij het implementeren van een netwerk-managementsysteem: er is geen eenduidige managementinterface.

Volgende stappen

Als laatste is er nog een veel praktischer probleem bij het implementeren van OpenFlow in huidige netwerken: de hardware ondersteunt het protocol maar gedeeltelijk. Meerdere leveranciers hebben al hardware en software aangekondigd met OpenFlow support, maar over het algemeen zijn de implementaties zeer gelimiteerd. Desalniettemin wordt er langzaam vooruitgang geboekt en dus is het als operator aan te raden om OpenFlow te onderzoeken, uit te vinden welke features er nodig zijn en die zo snel mogelijk bij de leveranciers aan te vragen. AMS-IX heeft op meerdere conferenties ditzelfde opgeroepen naar aanleiding van een onderzoek naar eventueel gebruik van OpenFlow op haar platform. Het moge duidelijk zijn dat hardware-ondersteuning voor OpenFlow pas het begin is voor de lange weg naar SDN. Zonder gedefinieerde interfaces van en naar de controllers lopen we de kans om weer in dezelfde valkuilen te lopen die we juist proberen te vermijden.


Michiel Appelman is NOC Engineer bij AMS-IX, na recent te zijn afgestudeerd als MSc Systems and Network Engineering.

Over Michiel Appelman

Laatste artikelen