qui indique au commutateur d’envoyer le paquet au contrôleur (ou à la commande normale
nonOpenFlow pipeline du commutateur). La priorité des règles suit le numéro d’ordre
naturel des tables et de l’ordre des lignes dans la table de flux. Possibilité d’avoir les
actions suivantes : transférer le flux vers le(s) port(s) sortant(s) ; l’encapsuler et l’envoyer
au contrôleur ; le rejeter ; l’envoyer au pipeline de traitement normal et l’envoyer à la table
de flux suivante ou à des tables spéciales, telles que la table de conteur introduites dans la
dernière version du protocole OpenFlow.
Figure 6 : OpenFlow activité sur les dispositifs SDN
4.1.1- Southbound API
Southbound API est l’une des composantes les plus critiques d’un système SDN,
qui fait le pont entre les dispositifs d’acheminement et le control plane. Il permet au
contrôleur de contrôler le comportement du réseau en gérant les entrées du flux de tous
les commutateurs sous-jacents.
L’API Southbound fournit une interface commune pour les couches supérieures
permettant au contrôleur d’utiliser les API vers le sud (par exemple OpenFlow, POF,
OpFlex et OpenState) et les plugins de protocole pour gérer les périphériques physiques
ou virtuels existants ou nouveaux (par exemple, SNMP, BGP et NetConf). Ceux-ci sont
essentiels à la fois pour la compatibilité et l’hétérogénéité de l’arrière-plan. Par
conséquent, sur le data plane, un mélange de dispositifs physiques, de dispositifs virtuels
(par exemple, Open vSwitch, vRouter) et une variété d’interfaces de dispositifs (par
exemple, OpenFlow, OVSDB, OFConfig, NetConf, et SNMP) peuvent
coexister.Actuellement, OpenFlow est le standard le plus accepté pour la norme de SBI.
Protocole OpenFlow
OpenFlow est standardisé par l’Open Networking Foundation (ONF). OpenFlow est
un protocole qui décrit l’interaction d’un ou plusieurs serveurs de contrôle avec les
commutateurs compatibles OpenFlow. Un contrôleur OpenFlow installe les entrées de
tables de flux dans les commutateurs, de sorte que ces commutateurs peuvent transférer le
trafic en fonction de ces entrées. Ainsi, les commutateurs OpenFlow dépendent de la
configuration des contrôleurs. La Figure 10 représente la position schématique du protocole
OpenFlow entre le plan de commande et le plan de données.
Figure 7 : Le protocole OpenFlow
OpenFlow peut acheminer des paquets sur la base de plusieurs critères, y compris IP,
MAC, VLAN et d’autres adressages, et ainsi fournir un solide remplacement pour le
routage sur IP. Le protocole OpenFlow a subi des améliorations rapides depuis la sortie
de nombreuses nouvelles versions. Le Tableau 2 ci-dessous résume quelques-unes des
améliorations significatives d’OpenFlow :
Version OpenFlow Support de Description
OF v1.1 MPLS, VLAN, Multipath, Tables grouper, Tables Multi flux et files
d’attentes.
OF v1.2 In-Match, Packet-In, En-têtes extensibles, Flux Flexible match et IPV6
OF v1.3 Tunneling, Packet-In de compteur et champs supplémentaires dans les
tables de flux (Priorité, Timeouts, Cookie)
OF v1.4 Gestion optique des ports, tables synchronisées, surveillance des flux
OF v1.5 Tables en sortie, statistiques d’entrée des flux, appariement des drapeaux
TCP en fonction du type de paquet et du type de canalisation
4.2- Control Plane
Les systèmes d’exploitation traditionnels fournissent des abstractions (par ex. API
de programmation de haut niveau) pour accéder aux périphériques de niveau inférieur,
gérer l’accès simultané aux ressources sous-jacentes (par ex. disque dur, adaptateur
réseau, CPU, mémoire) et fournir des mécanismes de protection. Ces fonctionnalités et
ressources sont des outils clés pour accroitre la productivité et faciliter la vie des
développeurs de systèmes et d’applications. Leur utilisation généralisée a grandement
contribué à l’évolution de divers écosystèmes (par ex. les langages de programmation) et
au développement d’une variété d’applications.
Le SDN est promis de faciliter la gestion du réseau et d’alléger le fardeau de la
résolution des problèmes de réseau au moyen du contrôle logiquement centralisé offert
par un système d’exploitation réseau (NOS). Comme avec les systèmes d’exploitation
traditionnels, la valeur cruciale d’un NOS est de fournir des abstractions, des services
essentiels et des interfaces de programmation d’applications (API) communes aux
développeurs. Les fonctionnalités génétiques telles que les informations sur l’état et la
topologie du réseau, la découverte des périphériques et la distribution de la configuration
du réseau peuvent être fournies en tant que services du NOS. Avec les NOS, pour définir
les politiques réseau, un développeur n’a plus besoin de se soucier des détails de bas
niveau de la distribution des données entre les éléments de routage, par exemple. On peut
soutenir que de tels systèmes peuvent créer un nouvel environnement capable de favoriser
l’innovation à un rythme plus rapide en réduisant la complexité inhérente à la création de
nouveaux protocoles et applications réseau.
4.2.1- Northbound API
La Southbound API a déjà une proposition largement acceptée (OpenFlow), mais une
Northbound API commune reste un problème ouvert. Pour l’instant, il est peut-être
encore un peu trop tôt pour définir une Northbound API standard, car les cas d’utilisation
sont encore en cours développement. Une abstraction qui permettrait aux applications
réseau de ne pas dépendre
d’implémentations spécifiques est importante pour explorer tout le potentiel du SDN.
Les contrôleurs existants tels que Floodlight, Trema, NOX, Onix et OpenDaylight
proposent et définissent leurs propres Northbound API. Cependant, chacune d’entre elles
a ses propres définitions spécifiques. Les langages de programmation tels que Frenetic,
NetCore, Nettle, abstraient également les détails internes des fonctions du contrôleur et le
comportement du plan de données des développeurs d’application. De plus, les langues de
programmation peuvent fournir un large éventail d’abstractions et de mécanismes
puissants tels que la composition des applications, la tolérance aux pannes dans le data
plane et une variété d’éléments de base pour faciliter le développement des modules
logiciels et applications.
4.3- Application plane
Comme le montre la Figure 8, la couche d’application se trouve au-dessus de la
couche de contrôle. Grace à la couche de contrôle, les applications SDN peuvent accéder
facilement à une vue globale du réseau avec un état instantané par le biais de Northbound,
par exemple, le protocole ALTO (Application Layer Traffic Optimization). Dotées de ces
informations, les applications SDN peuvent mettre en œuvre par programmation des
stratégies pour manipuler les réseaux physiques sous-jacents en utilisant un langage de
haut niveau fourni par la couche de contrôle. Dans ce domaine, SDN propose le modèle «
Platform as a Service » pour la mise en réseau.
4.4- Type de contrôleurs SDN
Beacon : Beacon est un contrôleur SDN OpenFlow rapide, qui a été introduit en
2010. Il a été utilisé dans plusieurs recherches projets. C’est un contrôleur basé sur
Java. Il peut fonctionner sur de nombreuses plates-formes, y compris Linux
multicœurs haut de gammes, et les téléphones Android.
DISCO : Disco est un contrôleur distribué. Il est principalement utilisé pour les
réseaux
WAN et les réseaux superposés. Chaque contrôleur est responsable d’un domaine
réseau.
Les régulateurs communiquent entre eux par l’intermédiaire d’un canal inter-
contrôleur.
DISCO peut s’adapter dynamiquement à différentes topologies de réseaux
hétérogènes.
IRIS : IRIS est une plate-forme de contrôleur SDN pour contrôler la base
OpenFlow. Il peut gérer un grand réseau. IRIS prend en charge les architectures
qui sont évolutives horizontalement. Ainsi, les serveurs peuvent être ajoutés
dynamiquement au cluster de contrôleurs. Cela augmente le facteur de
performance du contrôle plane.
Maestro : Maestro est le premier système de contrôle OpenFlow qui exploite le
parallélisme. Dans Maestro, les programmeurs peuvent modifier la fonctionnalité
du data plane en écrivant des programmes simples à filetage unique. Maestro a
son propre ensemble des conceptions et des techniques qui aident le protocole
OpenFlow. Il s’agit d’un contrôleur basé sur Java et très portable pour différents
systèmes d’exploitation et architectures.
OpenDaylight : OpenDaylight s’inspire de Beacon. Il s’agit d’un contrôleur basé
de Java dérivé de Beacon. Il supporte OpenFlow et d’autres Southbound APIs.
L’OpenDaylight est présent dans sa propre machine virtuelle Java (JVM).
NOX : NOX est la première plate-forme SDN OpenFlow Controller pour la
construction d’applications de contrôle réseau. Il a été initialement développé par
Nicira Networks, aux côtés d’OpenFlow. Plus tard, NOX a été donné à la
communauté SDN. Les applications peuvent être en python ou en C++ et peuvent
être chargées dynamiquement.
POX : Pox est similaire au NOX Controller. POX est un contrôleur SDN qui
permet le développement et le prototypage rapides du réseau. Il suit le protocole
OpenFlow, et qui sert à jouer le rôle d’un framework entre les commutateurs
OpenFlow.
Floodlight : Floodlight est un contrôleur SDN Open source. Il s’agit d’un
contrôleur OpenFlow de classe entreprise, basé sur Java. Il fonctionne à la fois
avec les commutateurs physiques et les commutateurs virtuels qui utilisent le
protocole OpenFlow.
Ryu : Ryu est un contrôleur SDN basé sur des composants. Ryu signifie « flux »
en japonais. Ryu fournit de nombreux composants logiciels et API étendus pour
créer et gérer les applications réseau. Ryu supporte les protocoles comme
OpenFlow, Netconf, OF-config, etc. Ryu est complètement implémenté en
langage Python. Il est sous licence Apache 2.0.
5- Cas d’utilisation du SDN
Le marché du SDN est en constante évolution depuis son apparition sur la scène
mondiale en 2011, et ceci grâce aux nombreux avantages apportés par la technologie dans
les différents domaines. Ce qui fait que les cas d’utilisations sont très variés et s’étendent
sur toutes les parties du réseau.
5.1- QoS sur internet
Internet a toujours été une architecture qui ne garantit pas la stabilité, or les
services nouvelle génération de streaming vidéo, VoD ou autre Visioconférence sont très
peu tolérant des délais et erreurs de transmissions et nécessitent donc un réseau stable
pour l’acheminement des paquets. En se basant sur la vue centralisée du réseau offerte par
SDN, on peut sélectionner selon le débit, des chemins différents pour les divers flux de
trafic. C’est à partir de là qu’est né le concept du VoSDN (Video over SDN), une
architecture qui détermine le chemin optimal en se basant sur la vue globale qu’offre la
centralisation de contrôle (Benamrane, 2017).
5.2- Data center
Oracle SDN est un exemple de système qui fournit un réseau virtualisé du data
center. Ce système relie dynamiquement des machines virtuelles avec les serveurs de
réseau. À l’aide de l’interface du gestionnaire d’Oracle Fabric, la configuration et la
surveillance de réseau virtuel est possible en tout lieu, et le déploiement de nouveaux
services comme le pare-feu, l’équilibrage de charge et le routage devient à la demande
5.3- Réseaux mobiles
Avec l’avènement imminent de la 5G, les opérateurs se doivent d’optimiser leur
infrastructure de sorte à pouvoir gérer des masses de données de plus en plus importantes
tout en assurant la qualité de service qui accompagne une telle technologie. Le SDN est
une des pièces maitresses qui permettront aux opérateurs d’exploiter le potentiel de
l’infrastructure et permettre d’optimiser les débits au maximum tout en gardant une
importante visibilité sur le comportement de leurs équipements réseau.
5.4- Sécurité
La nature dynamique de SDN a été exploitée par un groupe de chercheurs qui ont
réussi à réduire de 99% le risque de récupération d’information par un analyseur de
paquet externe. Leur approche s’est basée sur une mutation aléatoire et assez fréquente de
l’adresse IP de l’hôte Des propositions ont été faites et notamment des mécanismes pour
contrer les attaques de déni de service (DDoS), Dans l’architecture suggérée, deux éléments
clés ont été exploités : Les IDS pour la détection d’intrusions intra-LAN et les switchs Openflow
pour l’isolation dynamique des équipements infectés.
