Le projet OpenDaylight (ODL) est une plate-forme collaborative et open source pour accélérer l’adoption et l’innovation de la mise en réseau logiciel (SDN) et de la visualisation des fonctions réseaux (NFV). ODL est un logiciel basé sur Java et pris en charge par l’industrie, géré par le consortium Linux Foundation avec près de 50 entreprises membres, dont Brocade, Cisco, Citrix, Dell, Ericsson, HP, IBM, Juniper, Microsoft et Red Hat. La mission d’ODL est de créer une communauté collaborative qui partage et contribue au succès et à l’adoption du SDN.
Architecture OpenDaylight
L’architecture de l’OpenDaylight ressemble comme pour la plus part des architectures SDN à une architecture classique sur trois (03) couches qui sont à savoir : La couche application, la couche contrôleur et enfin la couche infrastructure réseau. La figure (1) représente une architecture simplifiée d’OpenDaylight.
Si l’on devait donner une définition simplifiée pour chacune des trois (03) couches on dira que :
- La couche application : Possède l’application client qui permet de programmer le réseau physique. L’interface application client possède les fonctionnalités que le client peut opérer sur son réseau. Les fonctionnalités qui sont donc visualisables sur l’interface graphique du client et donc cliquables vont alors déclencher l’exécution d’APIs qui vont interagir avec la couche du contrôleur. On parle alors d’APIs Nord (NB APIs). ODL utilise deux APIs nord qui sont : REST API et OSGi APIs. Elles sont définies de la manière suivante :
The ODL supports both OSGi framework and bidirectional REST APIs for the NB APIs. The difference between the OSGi framework and REST (HTTP based) API is that, the former is used for applications that will run in the same address space as the ODL whereas the latter is used for applications that do not.
- La couche contrôleur : Cette couche est celle du contrôleur. Elle communique avec la couche application via les APIs cité plus haut ainsi que la couche infrastructure réseau (qui contient tout le matériel réseau). Cette couche permet de récupérer les APIs de la couche application et de les exécuter afin de comprendre le comportement qu’elle souhaite exécuter sur le matériel réseau. Une fois le comportement extrait, cette couche se charge de transférer cette information à la couche infrastructure réseau pour que le comportement puisse prendre effet sur le métier ciblé par l’application. La communication entre le contrôleur et la couche infrastructure se fait via des APIs nommés API Sub (SB APIs). [] définis la communication entre les deux couches par :
“ A secured southbound (SB) interface is established between each element of the underlying entire network and the controller, through which the rules are forwarded. Networking elements store the rules in a chain of flow tables and when no entry matches the packet header fields of a received packet in the flow tables, routers or switches send it to the controller. If a matching rule is found, the defined action (drop, forward to a certain port) is applied. If no matches found, the packet can be either dropped or sent to the controlle. ”
On note donc, que la communication entre la couche infrastructure et la couche contrôle se fait via des API SUDs. Cette communication est établie grâce au SAL de la couche de contrôle qui communique via des APIs SUD avec les équipements réseaux (par exemple via le standard OpenFlow). Le SAL est donc le cœur du contrôleur ODL.
- La couche infrastructure réseau : est composée de divers équipements de réseaux qui forment le réseau sous-jacent pour acheminer le trafic du réseau. Il peut s’agir d’un ensemble de commutateurs et de routeurs de réseaux dans le centre de données. Cette couche serait la couche physique sur laquelle la virtualisation du réseau serait établie par l’intermédiaire de la couche de contrôle (où les contrôleurs s’associeraient t et géreraient le réseau physique sous-jacent).
