Nous ne perdrons pas de vue que le SD-WAN est avant tout une technologie de transport de paquets IP (v4 ou V6) qui la capacité de gérer les éléments suivants :
- utiliser un ensemble de liens (physiques ou logiques) hétérogènes
- disposer d’une classification de flux applicatifs (non seulement sur la base de l’information de routage, de transport, ou session, etc.)
- router les flux par application (et non seulement par adresses destination ou source, etc.)
- intégrer (nativement) l’interconnexion avec les environnements Cloud
- permet (par définition) un contrôle et un déploiement centralisé
- gérer intelligemment les flux appartenant à des zones de sécurité différents (internet, intranet, etc.)
Exemple d’une architecture logique
L’exemple de Cisco définit quatre rôles des composantes d’une architecture logique SD-WAN: un manager, contrôleur, validateur et équipement de périphérie (ou edge). Les équipements de périphérie se situent au plus proche des sites distants, à connecter; il s’agit d’un équipement physique ou virtualisé et par la même occasion embarque aussi le bout de “système” qui est le validateur. Le processus validateur sur tous les edges, gère la connexion des edge aux contrôleurs (gestion du NAT, DTLS, etc.). Le contrôleur gère tous les edges; c’est en quelque sorte “la tête pensante”, une intelligence centralisée qui associent par les tunnels DTLS tous les edges et gère leur opération. Le manager permet de visualiser tout ça du point de vue du contrôleur (et donne accès aux API pour les besoins de développement)…
Dans la suite nous présentons 3 déploiement possibles du SD-WAN: physique, could SD-WAN ou tout simplement cloud. Cela n’exclut pas qu’une solution puisse comprendre toutes ces variantes, on dirait alors que le déploiement est hybride
