Dans ce modèle, les applications sont écrites avec un ensemble d'API qui sont fournies par le contrôleur de SDN. Malheureusement, ces API ne sont pas standardisées, une application qui s'exécute sur un contrôleur donné SDN devrait être modifiée pour fonctionner sur un autre contrôleur.

Le contrôleur de SDN embarque un certain nombre de règles qui contrôlent le comportement des éléments de réseau sous-jacents, de sorte que le réseau fournira les services de réseau souhaités. Le dispositif de commande fournit des fonctions de gestion pour la performance et des défauts via SNMP, ainsi que d'autres protocoles standards. Le contrôleur gère la configuration des dispositifs compatibles avec OpenFlow afin de fournir la gestion de la topologie du réseau, de la transmission, de la qualité de service et des liaisons.

Les commutateurs Ethernet et les routeurs les plus modernes contiennent des tables de flux (typiquement supportées par la mémoire adressable de contenu ternaire) qui fonctionnent à la vitesse de la ligne et sont utilisées pour effectuer des fonctions de transfert selon  les couches 2,3 et 4, indiquées dans les en-têtes de paquets. Bien que chaque fournisseur ait des tables de routage différentes, il existe un ensemble commun de fonctions pour une large gamme de commutateurs et de routeurs. Ce socle de fonctions est mis à profit par OpenFlow, qui est un protocole ouvert entre un contrôleur central et un commutateur gérant ce protocole et qui, comme indiqué, peut être utilisé pour programmer le comportement de retransmission du commutateur.

Avec OpenFlow, un seul contrôleur central peut programmer tous les commutateurs physiques et virtuels dans un réseau. Bien qu'il soit possible de mettre en oeuvre un SDN avec un seul contrôleur, des fournisseurs tels que Big Switch et NEC ont annoncé soit un cluster à haute disponibilité soit leur intention de mettre en oeuvre un tel groupe de contrôleurs. Il est probable qu'IBM suivra.

Une montée en puissance lente

Il ne fait aucun doute que le SDN peut apporter une valeur très importante pour les DSI. Mais dans le contexte actuel, il est seulement approprié pour les pionniers.  Compte tenu de l'immaturité des produits actuels, des normes et des API, toute organisation informatique qui cherche à mettre en oeuvre un SDN à court terme ne doit le faire que d'une manière quelque peu limitée pour une utilisation très spécifique.

En outre, étant donné l'état embryonnaire du marché, l'interopérabilité des produits qui prétendent soutenir les mêmes normes connexes de SDN ne peut être garantie. Dès lors, les organisations informatiques ne devraient travailler qu'avec des fournisseurs qui ont démontré un niveau élevé d'interopérabilité.

Toutefois, compte tenu des énormes investissements que les vendeurs font, combinés avec la vague d'acquisitions en cours, le paysage du SDN est susceptible de changer, notamment au cours des 12 à 18 prochains mois. Les organisations informatiques peuvent s'attendre à une série d'annonces à la fois en termes de produits, des protocoles et une amélioration de l'interopérabilité.

Les directions informatiques peuvent également s'attendre à ce que les blocs de base de construction d'un SDN, tels que les protocoles et les API, vont se stabiliser. En partant du principe que tout cela se concrétise, il y a deux événements qui doivent se produire pour que le SDN puisse passer du statut de « strictement pour les pionniers » à  au «prêt pour le marché grand public ».

Le premier est la disponibilité d'une fonction qui permette aux organisations IT de gérer efficacement cette future forme de réseau. Le second est la disponibilité d'une large gamme d'applications qui tirent parti de la centralisation de la commande inhérente à la plupart des formes de SDN et qui réponde à la question que tous les responsables informatiques vont se poser: «Pourquoi devrions-nous dépenser nos ressources sur du SDN. Quels sont exactement les avantages? »