ONOS

1. Définition :
Open Network Operating System (ONOS) est le principal contrôleur SDN à source
ouverte pour la création de solutions SDN/NFV de nouvelle génération.
(ONOS) est le premier système d'exploitation de réseau SDN à source ouverte destiné
spécifiquement au fournisseur de services et aux réseaux critiques. ONOS est conçu
pour fournir la haute disponibilité (HA), l'extensibilité et la performance que ces
réseaux exigent. ONOS va : - apporter des caractéristiques de qualité opérateur (échelle,
disponibilité et performance) au plan de contrôle du SDN - permettre une agilité de type
Web - aider les fournisseurs de services à migrer leurs réseaux existants vers des boîtes
blanches - réduire les coûts d'investissement et d'exploitation des fournisseurs de
services.

2. Historique :
(ONOS)Les pionniers qui ont formé le noyau de l'écosystème SDN se sont réunis en
2011 pour créer l'Open Networking Research Center (ONRC) et l'Open Networking Lab
(ON.Lab). Selon le site web, l'ONRC fait partie de l'université de Stanford et l'ON.Lab
développe, déploie et prend en charge des outils et des plateformes SDN à source
ouverte. L'ONOS est un système distribué - une plateforme de contrôle SDN conçue
spécifiquement pour l'évolutivité et la haute disponibilité. Avec cette conception, ONOS
se projette comme un système d'exploitation de réseau, avec une séparation des plans
de contrôle et de données pour les réseaux étendus (WAN) et les réseaux de
fournisseurs de services.

3. Architecture :
L'architecture ONOS est conçue spécifiquement pour les exigences des réseaux de classe
opérateur en matière de performance, de haute disponibilité et d'échelle, avec des
abstractions bien définies :

4. Fonctionnement :
Le noyau de l'ONOS est basé sur une architecture modulaire, par opposition à un
système intégré qui brouille la division entre ses composants. Cette modularité permet
de séparer les flux de travail nord-sud des flux est-ouest tout en facilitant la
personnalisation de l'ensemble du système. Comme les fournisseurs de services doivent
pouvoir faire évoluer leurs réseaux, le contrôleur ONOS peut s'adapter à un système de
dispositifs physiquement distribués. Cela permet aux fournisseurs de services d'ajouter
de nouveaux commutateurs ou composants sans perturber le reste du système. En
outre, l'architecture distribuée réduit les pannes de réseau, car des instances identiques
peuvent se mettre en route là où une autre est défaillante. Il en résulte une haute
disponibilité.

Alors que le cœur de l'ONOS est distribué pour permettre l'accessibilité à chaque
dispositif de commutation du réseau, le contrôleur de l'ONOS reste logiquement
centralisé et les différentes subdivisions ou instances de l'architecture complète de
l'ONOS peuvent être visualisées et accessibles comme un seul système. Pour la visibilité
et la gestion de l'ensemble du système, ONOS fournit une interface graphique
relativement simple.

ONOS est doté d'interfaces de programmes d'application (API) nord et sud, basées sur
l'abstraction pour éviter le verrouillage de la configuration et du protocole pour les
applications et les dispositifs, respectivement. Pour les interactions vers le nord, ONOS
utilise son sous-système Intent Framework qui permet aux applications de spécifier ce
dont elles ont besoin à partir du système -- si une application a besoin de plus de bande
passante, par exemple. Une fois qu'une application déclare ce dont elle a besoin, le
système travaille pour configurer en conséquence. ONOS est conçu pour prendre en
charge un afflux de demandes d'intention d'application estimé à un million par seconde.
Cette capacité maintient la haute performance du système pour les demandes
d'application et la faible latence dont les fournisseurs de services ont besoin.

Chaque instance d'ONOS interagit avec l'environnement réseau et les périphériques par
le biais d'une API sud qui communique avec les composants de niveau inférieur. Le
noyau découvre quels protocoles peuvent être utilisés pour interagir avec l'appareil, et
l'API sud utilise ce protocole pour interagir avec l'appareil. Cette API est abstraite, de
sorte que l'ONOS n'est pas affecté par des protocoles spécifiques comme OpenFlow,
NETCONF ou les interfaces de ligne de commande.

5. Caractéristiques architecturales de l'ONOS :

5.1. Distributed Core :
Distributed Core ONOS est déployé en tant que service sur une grappe de serveurs, et le
même logiciel ONOS fonctionne sur chaque serveur. La symétrie du déploiement est une
considération importante de la conception car elle permet un basculement rapide en cas
de défaillance d'un serveur ONOS. L'opérateur de réseau peut ajouter des serveurs de
manière incrémentielle, sans interruption, selon les besoins pour augmenter la capacité
du plan de contrôle. Les instances ONOS travaillent ensemble pour créer ce qui apparaît
au reste du réseau et des applications comme une plate-forme unique. Les applications
et les dispositifs de réseau n'ont pas besoin de savoir s'ils fonctionnent avec une seule
instance ou avec plusieurs instances d'ONOS. Cette caractéristique rend ONOS évolutif -
on peut faire évoluer la capacité d'ONOS de façon transparente. C'est le noyau distribué
qui fait le gros du travail pour réaliser ces capacités.

5.2. Northbound abstraction/APIs :
Il existe deux puissantes abstractions liées au Nord : Le cadre d'intention et la vue
globale du réseau. Le cadre d'intention permet à une application de demander un
service au réseau sans avoir à connaître les détails de la manière dont le service sera
exécuté. Quelques exemples d'intentions : - Établir une connexion entre l'hôte A et
l'hôte B - Établir un chemin optique du commutateur X au commutateur Y avec une
largeur de bande Z - Ne pas permettre à l'hôte A de parler à l'hôte B.
The Global Network View fournit à l'application une vue du réseau - les hôtes, les
commutateurs, les liens et tout autre état associé au réseau tel que l'utilisation. Une
application peut programmer cette vue du réseau par le biais d'API. Une API permet à
une application d'afficher la vue sous forme de graphique réseau. Voici quelques
exemples de ce qui peut être fait avec le graphique du réseau:* créer une application
simple pour calculer les chemins les plus courts puisque l'application a déjà une vue
graphique du réseau * maximiser l'utilisation du réseau en surveillant la vue du réseau
et en programmant des modifications des chemins pour ajuster la charge (ingénierie du
trafic).

5.3. Southbound abstraction/APIs :

L'abstraction vers le sud est construite à l'aide d'éléments de réseau, tels que des
commutateurs, des hôtes ou des liens. L'abstraction de ONOS vers le sud représente
chaque élément de réseau comme un objet sous une forme générique. Grâce à cette
abstraction, le noyau distribué peut maintenir l'état de l'élément de réseau sans avoir à
connaître les spécificités de l'élément représenté par le pilote sous-jacent. Les
principaux avantages des abstractions vers le sud sont les suivants - la capacité de gérer
différents dispositifs utilisant différents protocoles - sans effet sur le noyau distribué du
système - la capacité d'ajouter de nouveaux dispositifs et protocoles au système.

5.4. Software modularity :

La construction des logiciels est importante. Bien conçus, les logiciels sont faciles à
améliorer, à modifier et à entretenir. L'équipe de l'ONOS a apporté un grand soin à la
modularité afin de faciliter le travail des développeurs avec le logiciel. Qu'est-ce que la
modularité ? C'est la façon dont le logiciel est structuré en composants et dont ces
composants sont liés entre eux. Comme le montre le diagramme ci-dessous, les
principales structures d'ONOS sont ses niveaux centrés autour du noyau distribué. La
modularité du logiciel présente de nombreux avantages :
- Intégrité et cohérence architecturales
- Structure de test simplifiée, permettant des tests plus complets
- Une maintenance plus facile avec moins d'effets secondaires des changements
- Extensibilité et personnalisation des composants
- Éviter les dépendances cycliques

ODL
6. Définition :
OpenDaylight (ODL) est une plateforme modulaire ouverte permettant de personnaliser
et d'automatiser des réseaux de toute taille et de toute envergure. Le projet
OpenDaylight est né du mouvement SDN, avec un accent particulier sur la
programmabilité des réseaux. Il a été conçu dès le départ comme une base pour des
solutions commerciales qui répondent à une variété de cas d'utilisation dans des
environnements de réseau existants.
OpenDaylight est la plate-forme de contrôle SDN open source la plus largement
déployée et, en seulement 6 ans, OpenDaylight compte 10 versions, plus de 1000
auteurs/soumissionnaires, 100K+ d'engagements, et alimente des réseaux de 1B+
abonnés dans le monde entier.
Le code d'OpenDaylight a été intégré ou incorporé dans plus de 35 solutions et
applications de fournisseurs, et peut être utilisé dans une gamme de services. Il est
également au cœur de cadres plus larges de logiciels libres, notamment ONAP,
OpenStack et OPNFV.
Dans le cadre du réseau LF Networking, l'ODL est dirigé par une communauté globale et
collaborative d'organisations de fournisseurs et d'utilisateurs qui s'adapte en
permanence pour soutenir le plus large ensemble de cas d'utilisation de SDN et NFV du
secteur.

7. Architecture :
L'ODL prend en charge une architecture en couches avec des points d'intégration et des
API clairs qui permettent aux utilisateurs finaux et aux fournisseurs de réseaux de
participer aux capacités de puissance du SDN de l'ODL. L'interface vers le sud de l'ODL
garantit que les technologies et le matériel de réseau de divers fournisseurs peuvent
être exploités à l'aide de l'ODL. L'interface nord fournit des API pour les utilisateurs
finaux et d'autres technologies de cloud computing telles que OpenStack. Le schéma
suivant illustre l'architecture de l'ODL :

8. L'architecture OpenDaylight

8.1. Model-Driven
Le cœur de la plate-forme OpenDaylight est la couche d'abstraction de services pilotée
par le modèle (MD-SAL). Dans OpenDaylight, les périphériques réseau et les
applications réseau sous-jacents sont tous représentés sous forme d'objets, ou de
modèles, dont les interactions sont traitées dans la couche SAL.
Le SAL est un mécanisme d'échange de données et d'adaptation entre les modèles YANG
représentant les dispositifs et les applications de réseau. Les modèles YANG fournissent
des descriptions généralisées des capacités d'un dispositif ou d'une application sans
qu'il soit nécessaire de connaître les détails spécifiques de la mise en œuvre de l'autre.
Au sein du SAL, les modèles sont simplement définis par leurs rôles respectifs dans une
interaction donnée. Un modèle "producteur" met en œuvre une API et fournit les
données de l'API ; un modèle "consommateur" utilise l'API et consomme les données de
l'API. Alors que les modèles "nord" et "sud" fournissent une vue d'ingénieur réseau du
SAL, les modèles "consommateur" et "producteur" sont des descriptions plus précises
des interactions au sein du SAL. Par exemple, le plugin de protocole et son modèle
associé peuvent être soit un producteur d'informations sur le réseau sous-jacent, soit un
consommateur d'instructions d'application qu'il reçoit via le SAL.
Le SAL met en relation les producteurs et les consommateurs à partir de ses magasins
de données et échange des informations. Un consommateur peut trouver un fournisseur
qui l'intéresse. Un producteur peut générer des notifications ; un consommateur peut
recevoir des notifications et émettre des RPC pour obtenir des données des
fournisseurs. Un producteur peut insérer des données dans le stockage du SAL ; un
consommateur peut lire les données du stockage du SAL. Un producteur met en œuvre
une API et fournit les données de l'API ; un consommateur utilise l'API et consomme les
données de l'API.

8.2. Modular and Multiprotocol

La plate-forme ODL est conçue pour permettre aux utilisateurs en aval et aux
fournisseurs de solutions de disposer d'une flexibilité maximale pour construire un
contrôleur répondant à leurs besoins. La conception modulaire de la plateforme ODL
permet à toute personne de l'écosystème ODL de tirer parti des services créés par
d'autres, d'écrire et d'incorporer les siens et de partager son travail avec d'autres.
L'ODL prend en charge le plus grand nombre de protocoles de toutes les plates-formes
SDN - OpenFlow, OVSDB, NETCONF, BGP et bien d'autres - qui améliorent la
programmabilité des réseaux modernes et répondent à toute une série de besoins des
utilisateurs.
Les protocoles et les services de plan de contrôle vers le sud, ancrés par le MD-SAL,
peuvent être sélectionnés ou écrits individuellement, et regroupés selon les exigences
d'un cas d'utilisation donné. Un ensemble de contrôleurs est construit autour de quatre
composants clés (odlparent, contrôleur, MD-SAL et yangtools). À cela, le développeur de
la solution ajoute un groupe pertinent de plugins de protocoles vers le sud, la plupart ou
toutes les fonctions standard du plan de contrôle, et un certain nombre d'applications
de contrôleurs embarqués et externes, gérées par la politique.
L'ODL est le principal lieu de développement et de test des différentes approches de la
politique et de l'intention telles que ALTO, Group Based Policy et Network Intent
Composition. Nous travaillons en étroite collaboration avec un certain nombre de
groupes industriels tels que l'Open Networking Foundation et l'IETF afin d'examiner et
de tester les différentes approches.
Chacun de ces composants est isolé en tant que fonctionnalité Karaf, afin de garantir
que les nouveaux travaux n'interfèrent pas avec le code mature et testé. OpenDaylight
utilise OSGi et Maven pour construire un paquet qui gère ces fonctionnalités Karaf et
leurs interactions.
Ce cadre modulaire permet aux développeurs et aux utilisateurs de :
• D’installer uniquement les protocoles et les services dont ils ont besoin
• Combiner plusieurs services et protocoles pour résoudre des problèmes plus
complexes au fur et à mesure des besoins
• Faire évoluer progressivement et de manière collaborative les capacités de la
plate-forme open source
• Développer rapidement des fonctionnalités personnalisées à valeur ajoutée pour
des cas d'utilisation hautement spécialisés, en tirant parti d'une plate-forme
commune partagée par l'ensemble du secteur

9. ONOS contre OpenDaylight

OpenDaylight (ODL) est un projet open source similaire créé par la Linux
Foundation. ONOS et ODL ont tous deux une conception modulaire et des
objectifs similaires pour faire progresser le SDN. Les deux projets adoptent
toutefois des approches distinctes et ont des bailleurs de fonds et des
partenaires différents. Alors que ONOS est principalement destiné aux réseaux
de fournisseurs de services, ODL se concentre sur les réseaux de centres de
données. De plus, l'objectif d'ONOS est de fournir une meilleure performance
globale du réseau, tandis que ODL est conçu pour fusionner les réseaux existants
avec SDN.