SDN ou comment le réseau s’automatise à grande échelle – Partie 1/2

Nous présentons dans cet article une évolution majeure dans les réseaux consistant à automatiser ou rendre programmable le réseau grâce au concept SDN. L’objectif est de rendre le réseau plus agile, mais aussi de faciliter le déploiement des services activés par les clients eux-mêmes.

1. Introduction

Le SDN (Software-Defined Networking) trouve beaucoup de définitions différentes. L’idée fondamentale derrière le SDN est de rendre le réseau programmable, c’est-à-dire plus apte à subir des modifications liées à des demandes de services de plus en plus dynamiques. La RFC7149 [RFC7149] tente de définir le SDN de la manière suivante :

Le SDN (Software-Defined Networking) est un ensemble de techniques visant à  faciliter l’architecture, la livraison et l’opération de services réseaux de manière déterministe, dynamique et pouvant être déployés à grande échelle.

La technique principale utilisée est la mise à disposition d’interfaces de programmation (API) afin que des applications externes puissent directement interagir avec le réseau.

Une autre technique souvent utilisée et bien connue est la centralisation partielle ou totale du plan de contrôle d’un équipement réseau (son intelligence) laissant sur l’équipement le plan de transfert (contenant les tables de commutation) alimenté par ce plan de contrôle centralisé.

2. Les notions d’interfaces

Les outils et composants intervenant dans un processus donné (production par exemple) peuvent être hiérarchisés de la manière suivante :

  • les outils/composants se rapprochant du service client seront vers les couches « hautes » ;
  • les outils/composants se rapprochant du réseau physique seront vers les couches « basses ».

Cette approche de hiérarchisation reste très similaire à une vision telle que le modèle OSI (couches hautes applicatives, couches basses physiques). Le principe est que chaque couche de niveau N offre un niveau d’abstraction plus important à la couche N+1. Le nombre de couches dépend de l’architecture retenue par l’opérateur et du nombre d’outils/composants mis en jeu. Cependant, on peut définir de manière simple un modèle à quatre couches comme l’illustre la figure 1.

Fig. 1 : Architecture SDN en couches.


La couche de ressource représente le matériel physique des équipements réseaux (routeurs, pare-feux, etc.) et représente ainsi la couche la plus basse, donc la moins abstraite. Ces équipements réseaux représentent des ressources que le service pourra utiliser à la demande. Dans le cas de fonctions réseaux qui seraient virtualisées, la ressource serait la machine virtuelle ou le conteneur assurant la fonction réseau.

Il est possible d’accéder à la couche ressource par le biais d’une couche de contrôle (plan de contrôle) ou de gestion (plan de gestion). Ceci est très similaire au modèle en couches des équipements existant à la différence près que dans l’architecture SDN, un plan de contrôle et/ou gestion centralisé pourra être créé afin d’offrir une interface simplifiée à la couche de service (en gommant par exemple les disparités des équipements) et/ou d’amener plus de fonctionnalités. Le plan de contrôle ou de gestion aura alors la maîtrise de plusieurs ressources.

La couche service réseau s’assure du cycle de vie du service réseau. Elle va s’appuyer sur les couches de contrôle, de gestion (centralisée ou des ressources directement) afin de rendre le service demandé. La couche service réseau va exposer à la couche application un certain nombre de services pouvant être activés, ainsi que les paramètres associés à ces services. La couche application représente la couche la plus haute. Il peut également s’agir d’une application cliente qui interagit directement avec le fournisseur de service.

Les flèches entre les couches représentent des interfaces. Une couche peut disposer de flèches allant vers une couche plus basse, on parlera alors d’interface de service Sud. Elle peut disposer de flèches entrantes venant d’une couche supérieure, on parlera alors d’interface de service Nord.

Il existe des cas où des couches de même niveau discutent entre elles, c’est le cas notamment des plans de contrôle totalement ou partiellement distribués. On parlera alors d’interface de service Est/Ouest.

La figure 2 présente un exemple où un réseau est géré par deux plans de contrôle. Chaque plan de contrôle gère une partie des ressources réseaux. Une interface peut être nécessaire entre les deux plans de contrôle (besoin d’échange d’informations). C’est une interface de service Est/Ouest.

Fig. 2 : Interfaces SDN pour le plan de contrôle.


La notion de direction de l’interface est toujours pour une couche donnée. Ainsi du point de vue de la couche service réseau, celle-ci dispose également d’une interface de service Nord (venant de la couche application), cette interface expose les paramètres de service à l’application. Elle dispose également d’interfaces de service vers les couches de contrôle et de gestion.

Une interface représente un moyen pour une couche d’exposer des capacités de manière abstraite à une autre couche. Une couche peut donc utiliser plusieurs interfaces différentes pour une même direction. Ces différentes interfaces pouvant fournir des services différents ou le même service par une méthode différente. Les interfaces se basent sur des protocoles afin de permettre un dialogue.

La figure 3 illustre un exemple de couche de contrôle ayant trois interfaces de service Nord et trois interfaces de service Sud possibles. Elle propose l’utilisation d’une interface de type REST, l’utilisation du protocole NETCONF ou de la commande en ligne pour l’interface de service Nord. Concernant l’interface de service Sud, elle permet l’utilisation des protocoles PCEP, BGP-LS ou XMPP. En terme d’usage, PCEP serait par exemple utilisé pour la création de tunnels d’ingénierie de trafic, BGP-LS pour l’acquisition de la topologie du réseau en temps réel, et XMPP pour la mise en place de paramètres plus spécifiques.

Fig. 3 : De multiples interfaces pour une couche donnée.


3. La programmation du réseau par flux

Un constat de l’état des réseaux actuels est qu’il est complexe d’y ajouter de nouvelles fonctionnalités de manière simple (à des fins d’expérimentation par exemple) comme on pourrait le faire pour programmer un ordinateur.

Partant de ce constat, un étudiant de l’université de Stanford a réfléchi à la résolution de ce problème : comment programmer de manière simple, la sécurité, le routage (incluant l’ingénierie de trafic), les classes de service…, et en déduisit un besoin de séparation des différents composants des équipements réseaux (plan de gestion, plan de contrôle, plan de transfert).

L’idée est donc d’avoir des équipements matériels effectuant des fonctions de plan de transfert programmables via un protocole standard depuis un contrôleur centralisé. Ainsi sont nés le protocole Openflow et le concept de SDN. Le travail de spécification et d’évolution d’Openflow a depuis été repris par l’ONF (Open Networking Foundation).

Le principe d’Openflow est que le contrôleur au travers d’une interface de programmation peut programmer le plan de transfert des équipements du réseau de manière standard. Ainsi les industriels peuvent développer des équipements réseaux « simples » compatibles Openflow (incluant uniquement le plan de transfert), l’intelligence étant laissée au contrôleur Openflow. Le protocole Openflow représente donc une interface sud pour le contrôleur comme l’illustre la figure 4.

Figure 4 : Pipeline de traitement Openflow.


L’architecture d’un switch Openflow est structurée principalement autour des composants suivants :

  • un canal de communication Openflow avec le contrôleur ;
  • des tables de flux qui contiennent les informations de traitement sur les flux ;
  • des ports : il peut s’agir de ports physiques ou logiques (interface de Loopback, tunnels, agrégation de liens …).

Un switch Openflow peut être Openflow-only (c’est-à-dire qu’il ne supporte que les opérations de commutation issues d’Openflow) ou Openflow-hybrid (il peut alors se comporter également comme un switch de niveau 2).

Un switch Openflow utilise une ou plusieurs tables de flux qui contiennent donc des entrées. Chaque entrée est composée :

  • de critères permettant d’identifier le flux ;
  • de compteurs permettant d’avoir des statistiques sur le nombre de paquets pour un flux donné ;
  • d’instructions (d’actions) de traitement sur le paquet ;
  • une temporisation: au-delà d’un certain temps, si aucun paquet pour le flux n’a été vu, l’entrée de flux est supprimée.

Les entrées de flux sont créées par le contrôleur Openflow.

Cédric LLORENS, Stéphane LITKOWSKI & Denis VALOIS

La seconde partie de cet article sera publiée prochainement sur le blog, restez connectés 😉

Retrouvez cet article (et bien d’autres) dans MISC n°91, disponible sur la boutique et sur la plateforme de lecture en ligne Connect !

Laisser un commentaire