Exposé

Groupe I

Thème: sdN (software-difined-networking)

 Présentation des membres

 Ibrahima khalil KEITA (chef)

 Abdouramane CAMARA
 Safiatou DOUARE
 Daouda CAMARA
 Oumar FADIGA
 Yari CAMARA
 Fode mamoudou DOUK
 Abdoulaye SACKO
 Kerno abdourahamane BARRY
 Mohamed BEMBA
 Zaoro SAGNO
 Introduction

 Le SDN est certainement le sujet chaud qui agite le monde du

réseau depuis ces dernières années. Il est impossible d’avoir
un article, un tweet, un blog, une publication ou une
conférence sans ces trois lettres qui semblent vouloir tout
solutionner sur nos infrastructures. Dans une telle agitation,
les administrateurs réseau sont le plus souvent perdus.
 Qu’est ce que le SDN? Qu’est ce que l’openFlow? Qu’est ce
que cela nous apporte? N’est ce pas une technique pour nous
faire acheter leurs derniers commutateurs?
Définition:

 SDN signifie littéralement Software-Difined-Networking. C-a-d le réseau défini

par l’application. On comprend donc immédiatement que le sujet est vaste et
qu’il va être difficile d’avoir une définition unique. De puis la définition même du
SDN a changé avec le temps.
 Définition initiale: académiquement la définition a depuis largement évolue,
consistait a voir le SDN comme une architecture qui découplait les fonctions de
contrôles et de transfert des données du réseau (data plane) afin d’avoir une
infrastructure physique complètement exempte de tout service.
Dans ce modelé, les équipements réseau se contentent d’implémenter des règles,
injectées par les applications, de traitement des flux de données. Plus besoin
d’avoir sur ces équipements de protocoles de routage, spanning-tree, etc. : une
entité intelligente, appelée ‘’contrôleur’’ voit le réseau dans sa globalité et injecte
directement les règles de traitement des données sur chaque équipement.
Openflow:

Est le protocole défini par l’ONF (Open Networking foundation) pour transférer les règles définies dans
l’architecture SDN initiale.
Il permet par exemple à contrôleur d’injecter des règles sur des commutateurs ou des routeurs.
Openflow transmet des ordres au niveau du plan de données par exemple:
• Transférer les trames à destination de l’adresse MAC X vers l’interface Y en rajoutant le VLAN Z dans
l’entête 802.1Q
• Jeter les paquets ayant pour source ou destination l’adresse IPv6 A
• Encapsuler en GRE à destination de l’adresse IPv4 C tous les paquets IPv4 provenant de l’adresse D
OpenFlow est un composant de SDN mais c’est loin d’être la seule puisque cette technologie ne répond pas
directement au problématique rencontrées.
Modèle de programmation:

 Impératif:
Dans ce model, un programme connait exactement toute la suite des actions à réaliser pour
achever une action. Appliqué au SDN, cela revient à devoir injecter sur l’ensemble des
équipements tous les états nécessaires pour réaliser une action
 Déclaratif:
Dans ce model, le programme se focalise sur l’objectif. Chaque entité appelée par le programme
(un élément réseau dans le cas du SDN) va faire tout le nécessaire pour arriver à cet objectif en
reposant éventuellement sur une décision locale.
Ce second modèle semble aujourd’hui gagner du terrain sur le SDN pour de nombreuses raisons:
 Il est plus simple à mettre en œuvre puisqu’on va utiliser une intelligence déjà présente sur les
équipement;
 Il est plus robuste puisque les équipement réseau eux-mêmes peuvent réagir. Prenons simplement le
cas d’un protocole de routage: une décision prise localement sur un routeur sera toujours plus rapide
que reposer sur un ordre transmis par un contrôleur sur le réseau qui peut justement subir une panne;
 Il est préfère par les constructeurs qui acceptent plus facilement d’exposer l’intelligence de leurs
équipements s’ils restent complètement maitres de leur technologie.
Différents modelés pour le SDN

 Comme explique les sections précédentes, le SDN englobe toutes les solutions permettant une
programmation du réseau, afin de mieux interagir avec les applications. Diverses solutions coexistent,
adaptées selon les besoin des utilisateurs. On comprend aisément que les solutions permettant de
simplifier le déploiement d’une application dans un Datacenter ne sont pas les mêmes celles qui
permettront de mieux contrôler l’éclairage d’une ville a travers le réseau.
On peut noter différents modelés de programmable:
 Programmabilité individuelle de chaque équipement. Dans ce modelé une application interagit directement avec
chaque équipement via des API. L’application est centraliser ou peut être localisée directement sur l’équipement
réseau pour réaliser des taches spécifiques.
 Programmabilité via un contrôleur. Dans ce modèle, une application donne un ordre abstrait et global à un
contrôleur, qui à son tour traduit cette requête en une suite d’ordre auprès des équipement du réseau concerné. Ce
modelé est certainement le plus populaire puisqu’il permet de simplifier le réseau. Le contrôleur masque la
complexité du réseau. On peut distinguer plusieurs cas selon le type d’ordres échangés entre le contrôleur et les
équipements. Si au départ, il était une question d’avoir une programmabilité du plan de données (via Openflow par
exemple), des modelés dans lesquels des ordres plus abstraits sont données aux équipements, ces derniers restant
libres de les implémenter au mieux. On parle dans ce cas d’un modèle « policy-intent ».
 Création d’un réseau virtuel au dessus du réseau physique. Dans ce modelé, les applications créent leur propre
réseau « overlay », s’affranchissant des contraintes du réseau physique sous jacent. Ce dernier n’a pour mission
que la simple connectivité entre les nœuds d’extrémité des tunnels, et le réseau d’overlay assure l’intégralité des
services. On parle également de virtualisation des fonctions réseau (NFV – Network function virtualization) quand
les routeurs, commutateurs, firewalls, etc. sont des éléments virtualisés sur des serveurs.
 La programmation des équipements

 Les API (Application Programming interface):

La programmation des équipement réseau nécessite sur ces derniers la capacité de recevoir des directives de l’extérieur. Pour cela des interfaces de
programmation sont nécessaires: des API. Il existe de nombreuse API, standards ou propriétaires, pouvant agir sur différents éléments de
l’équipement (plan de données, plan de management…). Il est communément admis qu’une seule API universelle ne suffira pas pour résoudre toutes
les problématique réseau. Aussi les équipements modernes implémentent souvent plusieurs API.
La suite de cet article décrit API les plus communément supportées sur les équipement réseau:
• CLI : l’accès en ligne de commande au équipements via Telnet/Ssh est bel et bien une API et il est important de ne pas l’oublier! C’est
d’ailleurs encore celle qui est encore le plus souvent utilisée pour programmer/configurer les réseau. La CLI agit sur le plan
management.
• Netconf/Yang: Netconf est un standard IETF (RFC 6241) visant à standardiser les directives réseau auprès des équipements. Yang
est un langage permettant la modélisation des services réseau. Une directive Netconf pourra contenir un modèle Yang et ainsi
configurer de la même manière des équipements de constructeurs différents, si tant est qu’ils implémentent bien le service demandé et
cette API de configuration. Ce modèle standardisé est le plus souvent privilégié par les services providers qui cherchent au maximum à
être indépendants des constructeurs, sans pour autant perdre la maîtrise du réseau
• RESTful API (REpresentational State Transfer) : On parle de RESTful API quand les directives fournies sont faites via des directives de
type HTTP (GET, POST, DELETE…) La principale caractéristique d’une API RESTful est qu’elle est sans état. En outre, chaque requête
correspond à une demande. Il n’y a pas de dialogue possible entre les extrémités de la chaîne via une connexion préalablement établie.
On dénote l’API RESTconf qui permet d’échanger via une API RESTful un modèle Yang. Ces API sont plutôt privilégiées par les
communautés de développeurs web et seront plus souvent utilisées dans le contexte d’un Datacenter puisque cela correspond au
langage naturel de programmation des équipes en charge des applications.
• Opflex: est un protocole permettant à un Policy Repository (RP) de dialoguer avec des Policy Elements (PE) pour leurs demander de
réaliser une action abstraite. Il est adopté à un modèle de programmation déclaratif puisqu’on va se focaliser ici sur un objectif. Opflex
intègre une boucle de feedback permettant à un équipement réseau de fournir des informations clés au Policy Repository afin de l’aider
à prendre les bonnes décisions. Ce protocole en cours de standardisation à l’IETF. Il est davantage appliqué au niveau du Datacenter
puisque c’est aujourd’hui sur cet écosystème qu’il à été déployé par divers constructeurs.
• Autres… il existe de très nombreuse autres interfaces de programmation, plus ou moins ouvertes et adaptées à des environnements
spécifiques. Nous noterons dans le désordre et sans explication particulière: OVSDB, PCEP, BGL-LS, Python API, SNMP, LISP,
CAPWAP, HTTP, OVSDB, OpenFlow…
Quelle intelligence dans les équipements?
 Une des premières idées a émerge lors des débuts du SDN était que les équipements réseau allaient perdre toute
intelligence, ces derniers se contentant d’exécuter des ordres émis par les applications et les contrôleurs, entités surdouées
capables de tout faire. Quelques années plus tard, on observe que presque personne ne conserve cette vision. Le
contrôleur est avant tout un facilitateur pour répondre à de nouveaux besoins plus rapidement et il permet de simplifier
globalement le réseau. Chacun conçoit que chaque équipement réseau doit conserver une intelligence locale non
seulement pour réaliser des actions qu’il fait bien aujourd’hui, et ce de manière distribuée (routage, spanning-tree, agrégats
de lien, fonctions de sécurité,, etc.); mais aussi pour implémenter les directives complexes transmises par les applications.
 Effectivement programmer le réseau n’est possible que si chaque équipement offre une certaine dose de programmabilité.
Or, les équipements réseau sont très divers. Alors que certains ne doivent gérer que quelques kilobits par seconde pour
des applications spécifiques (distributeurs de billets, capteurs divers…), d’autres routeurs sur les cœurs de réseau
d’operateurs doivent commuter plusieurs térabits par seconde. Les différend entre les performances requises sur ces
matériels imposent des architectures radicalement différentes. La plupart des constructeurs intègrent et/ou développent des
ASICs (Application-Specific Integrated Circuits) permettant d’assurer les performances à coût relativement bas. Comme
leur nom l’indique, ces composants sont définis pour réaliser des taches prédéfinies et ne sont donc pour la plupart pas
programmables. Ils sont généralement un frein à l’innovation puisque chaque nouvelle fonctionnalité non prévu nécessite
ce que l’on appelle un « re-spin », c.-à-d. le développement d’une nouvelle version de l’ASIC. Certains systèmes combinent
un ASIC pour les opérations fixes qui délègue certaines fonctions complexes à des FPGA (Field Programmable Gate
Array) ou processeurs plus couteux. Dans ce cas aussi, il convient à l’avance d’anticiper ce qui doit être envoyé à ces
éléments intelligents.
 Aussi certains équipements ont créé des Network Proocessing Units (NPU) introduisant une dose de programmabilité tout
en conservant les performances réseau attendus. Ces composants, globalement plus couteux que les ASICs, peuvent être
reprogrammés pour implémenter les dernières innovations, comme par exemple un nouveau type d’encapsulation. Des
ASICs programmables sont également apparus sur le marché. De leur cote, les processeurs x86 ont aussi évolué pour
mieux gérer les paquets; ils peuvent assurer des performances toujours plus élevées, ouvrant la voie a la virtualisation des
fonctions réseau (ou NFV)… Nous pourrons retenir les 2 éléments suivants:
 les approches SDN n’ont pas pour objectif d’éradiquer tout plan de contrôle/management sur les équipements réseau. Au contraire elles
cherchent à mieux les exploiter;
 La programmation du réseau impose de nouvelles contraintes sur le plan de données des équipements réseau qui sont amenés à réaliser
des actions plus complexes.
P4 (Programming Protocol-Independent Packet Processors)

 Ce récent projet regroupant divers académiques et industriels illustre bien les conclusions de la section
précédente car il vise la programmation complète du traitement des données sur un équipement réseau. Au
lieu de programmer des états comme le fait OpenFlow, on va réellement programmer via un langage
abstrait baptise sur P4 le comportement d’un équipement réseau. Un algorithme de traitement d’un paquet
IPv4 pourra être simplement construit. Le format même des paquets est simplement défini dans le
programme et rajouter/modifier un en-tête relevé d’une simplicité enfantine. L’exemple ci-dessous montre
comment analyser (parser) une trame Ethernet. Il suffit de quelques lignes pour définir un nouveau format
de données.

1 Parser Ethernet{
2 switch(ethernetType){
3 case 0x8100 : vlan;
4 case 0x9100 : vlan;
5 case 0x0800 : ipv4;
6 case 0x86dd : ipv6;
7 }
8 }

 Une fois le programme créé, il suffit de le compiler pour qu’il puisse fonctionner sur le matériel désiré
(ASIC, FPGA, Network Processing, CPU…). A nouveau, le degré de programmabilité du matériel est la
clé pour réaliser les actions demandées avec les performances requises.
Les contrôleurs SDN
 Définition:
Certaines solutions SDN reposent sur la mise en place de contrôleurs. Ces derniers ont pour mission de fournir une
couche d’abstraction du réseau et de présenter ce dernier comme un système. Le contrôleur SDN permet
d’implémenter rapidement un changement sur le réseau en traduisant une demande globale (par exemple: prioriser
l’application X) en une suite d’opération sur les équipement réseau (requêtes Netconf, ajouts d’états Openflow,
configuration en CLI…).
Les ordres sont données au contrôleur par une application via une API dite « Northbound » ou nord. Les éditeurs
logiciels de contrôleurs publient la documentation de l’API afin de permettre d’interfacer des application.
Le contrôleur SDN communique avec les application via une API dite « Southbound » ou sud. Openflow se positionne
comme une API sud agissant directement sur le plan de données. D’autres API permettent d’agir sur le plan de
management ou de contrôle. Netconf est par exemple une API sud permettant au contrôleur de configurer un
équipement. Un contrôleur pourra même parler directement en CLI avec un équipement pour actionner une
fonctionnalité.
Open Daylight

 Alors que le consortium ONF s’est penché sur l’API Openflow permettant le contrôle du plan
de données, le consortium Open Daylight a été créé pour se pencher sur la problématique du
contrôleur, qui est un élément prépondérant de nombreuses architectures SDN. L’objectif de ce
consortium est de regrouper les efforts d’industriels et d’académiques pour développer un
contrôleur réellement utilisable dans des environnements de production (au-delà des quelques
laboratoires de recherche ou de sociétés dans le domaine de l’informatique ou le réseau). Ce
projet collaboratif, placé au sein de la Linux foundation, a permis le développement d’un
contrôleur, aujourd’hui dans sa troisième version: lithium.
 Nous pouvons noter la quantité d’interfaces sud (Openflow, OVSDB, Netconf, BGP, PCEP,
SNMP, HTTP, Opflex…) mettant en évidence qu’une seule API focalisée sur le Dataplane ne
suffit pas quand il es nécessaire d’assurer de nombreux services. Pour assurer l’intégration
simple d’une API sud, une couche d’abstraction appelée SAL (service Abstraction Layer) a été
conçue et reste un élément clé du contrôleur Open Daylight, permettant un développement de
nouveaux services sans lien direct avec les API utilisées pour les implémenter.
La virtualisation des fonctions réseau (NFV)

 Est une approche consistant à réaliser certaines fonctions réseau, traditionnellement effectuées sur du
matériel dédié, sur des serveurs x86. c’est une facette importante du SDN particulièrement étudiée chez les
fournisseurs de services qui voient ici une solution pour mieux ajuster l’investissement selon les besoin de
leurs clients. Au lieu de déployer du matériel ad-hoc pour chaque demande, l’operateur va piocher dans une
capacité de calcul globale, facilement extensible via l’ajout de serveurs.
Il y’a 3 grandes problématiques associées aux approches NFV:
 Il n’y a plus un réseau à gérer mais plusieurs réseaux (dont le réseau physique). A première vue cela semble contraire à l’un
des objectifs du SDN : la simplification des opérations réseau;
 L’interconnexion de réseau virtuel au reste du monde, à l’internet. Les overlays restent le plus souvent confinés à certains
domaines, comme le Datacenter, et l’interconnexion reste nécessaire via passerelles qui doivent supporter les protocoles du
modèle overlay tout en garantissant les performances requises;
 Le réseau sous-jacent ne voit plus grand-chose de ce qu’il transporte, puisque le trafic est encapsulé en amont dans un
protocole ad-hoc comme par exemple VXLAN ou NVGRE;

 Une approche NFV nécessite souvent un niveau d’expertise additionnelle en amont et une modification
dans l’organisation des équipes en charge des serveurs/applications et du réseau. Les équipes réseau ne
peuvent accepter de reposer sur des serveurs que s’ils ont la garantie de leur bon fonctionnement. Pour
beaucoup d’organisation aujourd’hui, cela est un frein. Les service providers sont les plus avancés sur le
NFV car ils ont davantage les capacités de faire face aux challenges du NFV: le réseau est leur métier.
Pour autant les déploiements massifs d’architectures NFV N’en sont encore qu’à leurs prémices.
Programmation bout en bout: le rôle de l’orchestrateur

 Comme explicité précédemment, les solutions SDN vont varier selon le type d’environnement
(WAN, LAN, Datacenter…) et comme c’est le cas aujourd’hui pour les solutions de management
traditionnelles, des solutions indépendantes sont souvent déployées chaque domaine.
 Or, la nécessité de programmation existe de bout en bout. Si l’application est déployée dans un
Datacenter, les usagers peuvent être connectés en WI-FI, connecté au LAN, derrière le WAN et
des firewalls ou autres dispositifs réseau. Il est illusoire de penser qu’un seul contrôleur pourra
programmer l’ensemble de la chaîne. La première raison est que les cycles d’acquisition de tous
ces éléments sont différents aujourd’hui dans les organisations. L’autre raison est que la plupart
des organisations veulent cloisonner ces domaines pour garder davantage de liberté, mais
également parce qu’elles sont elles mêmes organisées en silos avec des équipes en charge
directement d’un sous-ensemble du réseau.
 Dans les modèles SDN actuels, ce n’est pas le contrôleur mais l’orchestrateur qui va offrir cette
fonction de programmation de bout-en-bout. Ce dernier reçoit un ordre depuis une application
(par exemple un portail de fourniture de service) et réalise ensuite la suite d’actions nécessaires
pour mener à bien la tâche demandée. Pour réaliser sa mission, l’orchestrateur va pouvoir
s’appuyer pour chaque élément de la sur le/les contrôleurs déployés.
 L’orchestrateur travaille généralement en mode dit « transactionnel ». Il doit être capable de
valider chaque étape quand il réalise une action afin de revenir en arrière en cas d’échec. Il ne
peut pas laisser dans un mode bancal où seule une partie aurait été configurée avec un nouveau
service.
conclusion

 Le Software Difined Netwoking annonce des changements importants sur les réseaux dans les
années a venir. Ceux-ci vont voir leur architecture profondément évoluer, facilitant des
nouveaux usages. Tout cela sera permis grâce à la programmabilité, l’ouverture, la
virtualisation et l’orchestration. Aucun domaine ne semble épargné: WAN, Datacenter,
campus, sécurité… L’enjeu pour les administrateurs réseau est d’accompagner cette nouvelle
étape afin de pouvoir tirer profit de ces nouvelles capacités.

Bibliographie:

https://www.zestedesavoir.com
https://www.developpez.net
https://www.w3schools.com
https://www.pdf-drive.com
https://www.fr.m.wikipedia.org
https://www.openclassrooms.com
Remerciement