E. Haleplidis (University of
Patras)K. Pentikousis
(EICT)S. Denazis (University of
Patras)J. Hadi Salim (Mojatatu
Networks)D. Meyer
(Brocade)O. Koufopavlou (University of
Patras)January20152015-01-09
S'il y a un buzzword
populaire en ce moment, dans les technologies de réseau, c'est bien
SDN. Ce sigle désigne une approche de contrôle
centralisé d'un réseau, par le biais d'ordres envoyés depuis la
machine d'administration, vers tous les éléments actifs du réseau (les
routeurs, par exemple). Comme tous les
buzzwords, son utilisation massive pour désigner
tout et n'importe quoi entraîne pas mal de confusion, et ce
RFC de l'IRTF essaie de clarifier un peu en précisant la
terminologie du SDN (Software-Defined
Networking), et en explorant les protocoles actuels qui
participent au système SDN.
Le problème est d'autant plus difficile que tout le monde veut
être SDN aujourd'hui. Si, comme la plupart des
administrateurs réseaux professionnels,
j'utilise un script qui utilise SSH pour se
connecter sur tous mes routeurs
afin de changer leur configuration, je fais du SDN ? (Réponse : oui,
selon la plupart des définitions de SDN qu'on peut trouver, non selon
les marketeux, car cette solution ne permet pas de nouvelles ventes.)
La définition que donne le RFC est « le SDN, c'est une approche du
réseau fondée sur la programmabilité, qui sépare le plan du contrôle
de celui de la transmission, et qui utilise des interfaces
standardisées ». Une interface est là où deux
entités interagissent. Ce peut être fait avec un protocole réseau, ou
une API locale. Le maître d'un réseau SDN (le
contrôleur) va
configurer des éléments du réseau (network device),
les engins qui assurent les fonctions comme la transmission des
paquets. Le logiciel utilisé se divise entre
applications (qui sont un but en elles-mêmes) et
services (qui n'existent que pour fournir des
fonctions aux applications, via une jolie
API).
Et ces histoires de plan dont j'ai parlé plus
haut ? Un plan est une collection de ressources (matériel et logiciel)
qui sont responsables d'une activité donnée. Le RFC distingue cinq plans :
Plan de transmission (forwarding plane) :
faire suivre les paquets d'une interface à l'autre,Plan de contrôle (control plane) : détermine
les règles que va suivre le plan de transmission. Par exemple, sur un
routeur haut de gamme, le plan de contrôle, qui tourne sur du matériel
généraliste, fait tourner les protocoles comme
BGP ou OSPF, déterminant
la table de routage, tandis que le plan de transmission, composé
d'ASIC spécialisés, utilise cette table de
routage pour transmettre les paquets à la bonne interface.Ces deux premiers plans sont classiques et souvent utilisés dans
les discussions réseau. Le RFC en ajoute trois autres : d'abord, plan des
opérations (operations plane, la gestion globale de
la machine), et plan de gestion (management plane,
la supervision et la configuration de la machine).Et enfin, le plan des applications (application
plane), qui comprend les services et les applications
proprement dites.
Le RFC introduit aussi le concept de couche d'abstraction (AL,
Abstraction Layer), qui est la vision qu'une
ressource va présenter au monde extérieur. Ainsi, le DAL
(Device Abstraction Layer, aussi appelé HAL pour
Hardware Abstraction Layer), est la vision externe
d'un engin, ce que connaitra le reste du monde. Il y a de la même
façon un CAL (Control Abstraction Layer), un MAL
(Management Abstraction Layer) et un NSAL
(Network Services Abstraction Layer). Oui, moi
aussi, je trouve cela bien abstrait.
La section 3 détaille certains de ces concepts. On a, de bas en
haut (en mettant en bas ce qui est concret et en haut ce qui est utile) :
L'élément du réseau, par exemple un
commutateur, qui contient le plan de
transmission et celui des opérations, et qui montre à l'extérieur le
DAL. Il est décrit plus en détail en section 3.2.Côte-à-côte, les plans de contrôle (faisant appel au CAL) et de
gestion (faisant appel au MAL). Sur un engin
ancien, ils sont intégrés aux précédents mais le SDN prône leur
séparation (qui était réalisée depuis longtemps dans les routeurs),
pouvant aller jusqu'à les mettre dans des machines différentes. La
distinction entre ces deux plans est subtile, l'intéressante section 3.5 la traite
plus en détail. En gros, le plan de contrôle s'occupe plutôt de
réactions rapides (genre moins d'une seconde), et a des états de
courte durée (genre une minute). Le plan de gestion prend en charge
des phénomènes moins rapides.Les services et applications, parlant au NSAL.
Le avait déjà un schéma de ce genre. Comme on
représente les composants avec le matériel en bas et les applications
et services en haut, les interfaces sont souvent étiquetées « Nord »
et « Sud » selon qu'elles connectent à un composant situé plus haut ou
plus bas (et tant pis pour les Australiens qui
mettent le Nord en bas). Ainsi, l'interface du plan de gestion
avec le plan des opérations (via le DAL) est, pour le plan de gestion, une
Southbound interface (MPSI : Management
Plane Southbound Interface).
Le RFC note que, pour le plan de gestion, la facilité d'usage doit
être un critère plus important que les performances (cf. ) ce qui implique entre autres des fichiers
de configuration sous forme texte, en UTF-8
(cf. ). Il existe déjà plusieurs
protocoles pour la communication Sud du plan de gestion, par exemple
NETCONF (),
ForCES (), et
même les bons vieux syslog () et SNMP ().
La section 4 met tout cela en perspective dans le cas du SDN,
notamment en regardant où les protocoles existants se situent. En
gros, les contrôleurs SDN existants sont plutôt dans le plan de contrôle
et utilisent son interface Sud (CPSI, Control Plane
Southbound Interface) pour parler au matériel. Le protocole
utilisé pour cela est typiquement
OpenFlow. Leur interface Nord (le NSAL) n'est
pas normalisée.
Pour les protocoles IETF existants, quelle
est leur place dans ce schéma ? Commençons par
ForCES (). L'idée
de base est de normaliser le protocole de communication entre le plan
de contrôle et celui de transmission, afin de pouvoir réaliser un
routeur en combinant un control/routing engine et un
forwarding engine de fournisseurs différents, ce
qui est impossible aujourd'hui. Si ForCES vise surtout la
communication entre plan
de contrôle et plan de transmission, il est assez souple (définition
des éléments gérés indépendante du protocole) pour pouvoir peut-être
s'utiliser pour des communications avec le plan de gestion et le plan
des opérations.
Le protocole NETCONF () est, lui, un protocole de gestion à distance
d'équipement réseau (qui pourrait remplacer le traditionnel script qui
se connecte en SSH sur tous les équipements
avant de configurer avec la CLI). Il est donc
partiellement concurrent de SNMP, notamment pour les opérations de
modification (set en SNMP). Et NETCONF, dans le
monde SDN, peut servir de MPSI (Management Plane Southbound
Interface). Son langage de
modélisation, YANG (), semble très populaire en ce moment à l'IETF.
Au contraire de ForCES et de NETCONF, issus directement de l'IETF,
OpenFlow vient du privé
(université Stanford) et est géré aujourd'hui par une organisation
ad hoc, Open Networking Foundation. Son but est
de contrôler de manière centralisée un ensemble de
commutateurs réseau. C'est entre autres un DAL
(Device Abstraction Layer) pour le CPSI
(Control Plane Southbound Interface).
Dans un routeur classique, la base d'informations (RIB,
Routing Information Base) est gérée par les
protocoles dynamiques comme OSPF et a peu
d'interfaces vers l'extérieur. On peut définir des routes statiques,
on peut obtenir quelques statistiques et de la
journalisation mais on n'a pas d'interface
standard avec le système de routage, permettant de manipuler davantage
celui-ci. Le but du projet I2RS
(Interface to the Routing System) à l'IETF est
justement de spécifier cette interface, en utilisant
YANG et en réutilisant autant que possible des
systèmes existants. Le projet en est actuellement à ses débuts.
Tous ces protocoles nouveaux et qui brillent ne doivent pas faire
oublier les traditionnels, comme SNMP. Après
tout, le terme « SDN » est en grande partie du marketing, le contrôle
des éléments réseau via des protocoles se pratiquait longtemps avant que
le sigle SDN soit inventé. Donc, SNMP (,
, ) est
un protocole de gestion de réseaux, actuellement dans sa version
3. Les objets définis dans une MIB peuvent être
interrogés (get) et modifiés
(set mais, en pratique, c'est bien plus rare
qu'on utilise SNMP pour cela). Comme NETCONF, il peut servir de
MPSI.
Deux autres protocoles sont moins souvent cités lorsqu'on parle de
faire du SDN avec les protocoles IETF existants mais ils méritent
quand même une mention. D'abord, PCE (), qui vise à réaliser le calcul de chemins dans le réseau
en un endroit différent de celui qui fera la transmission. Par
exemple, une machine spécialisée, le PCE (Path Computation Element) va calculer des routes et les
transmettre au routeur, le PCC (Path Computation
Client), via le protocole PCEP (PCE communication
Protocol, ). Au contraire de la plupart des
protocoles vus ici, qui sont Nord-Sud (communication entre des entités
de niveau différent), PCEP est Est-Ouest (on peut dire aussi
« horizontal », mais le terme n'est pas dans le RFC) faisant communiquer des
machines situées au même niveau conceptuel.
Et enfin le protocole BFD (), un protocole de détection de pannes dans les
routeurs, prévu pour être très rapide, afin de détecter les problèmes
plus tôt que par les techniques de gestion classiques. C'est
conceptuellement un service du plan de contrôle.
Pour résumer ? Lire la section 5 et bien se rappeler que 1) SDN ne
se limite pas à utiliser OpenFlow 2) Il y a beaucoup de marketing et
beaucoup moins de substance.
Quelques lectures classiques citées par notre RFC (la
bibliographie de ce RFC est particulièrement longue, reflet de la
complexité, de la richesse, et de la confusion du sujet). D'abord, les
articles historiques :
« A survey of programmable
networks » de Campbell et T. Andrew (ACM
SIGCOMM Computer Communication Review 29.2 (1999)),« OpenFlow: enabling innovation in
campus networks » de McKeown et Nick (ACM
SIGCOMM Computer Communication Review 38.2 (2008)),« Network virtualization: state of the
art and research challenges » de Chowdhury, NM
Mosharaf Kabir, et Raouf Boutaba (Communications Magazine,
IEEE 47.7 (2009)),« A clean slate 4D approach to
network control and management » de Greenberg, Albert
et autres (ACM SIGCOMM Computer
Communication Review 35.5 (2005)),Puis une histoire du concept de SDN dans « The
Road to SDN » de Feamster, Nick, Jennifer Rexford, et
Ellen Zegura (ACM Queue11, no. 12 (2013)),Une étude de l'état du SDN en 2014, « A Survey of
Software-Defined Networking: Past, Present, and Future of
Programmable Networks » de Bruno Astuto A. Nunes,
Marc Mendonca, Xuan-Nam Nguyen, Katia Obraczka, et Thierry Turletti
(IEEE Communications Surveys and Tutorials DOI:10.1109/SURV.2014.012214.00180),Le .