inlinetoc

OpenDaylight est un projet open source collaboratif hébergé par The Linux Foundation. L'objectif du projet est de promouvoir la virtualisation des fonctions de réseau et des fonctions réseau définies par logiciel (Software-defined networking). Le logiciel est écrit en langage de programmation Java.

Installer l'une des version d'opendaylight

$ rpm -ivh https://cbs.centos.org/repos/nfv7-opendaylight-5-testing/x86_64/os/Packages/opendaylight-5.5.0-0.1.20170917rel1979.el7.noarch.rpm

$ rpm -ivh https://nexus.opendaylight.org/content/repositories/opendaylight-epel-7-x86_64-devel/org/opendaylight/integration-packaging/opendaylight/8.2.0-1.el7.noarch/opendaylight-8.2.0-1.el7.noarch.rpm

Afin de permettre le téléchargement des features renseigner le proxy dans ~/.m2/settings.xml:

 <settings>

      <proxies>
       <proxy>
          <id>example-proxy</id>
          <active>true</active>
          <protocol>http</protocol>
          <host>proxy.infra.dgfip</host>
          <port>3128</port>
          <username>proxyuser</username>
          <password>somepassword</password>
          <nonProxyHosts>www.google.com|*.example.com</nonProxyHosts>
        </proxy>
      </proxies>

</settings>

• Démarrer le démon

$ systemctl start opendaylight

• ou exécuter l'application standalone

$ /distribution-karaf-0.5.0-Boron/bin/start

Se connecter à la console avec user/mdp=karaf/karaf:

$ ssh -p 8101 karaf@localhost

Password authentication
Password:

    ________                       ________                .__  .__       .__     __
    \_____  \ ______   ____   ____ \______ \ _____  ___.__.|  | |__| ____ |  |___/  |_
     /   |   \\____ \_/ __ \ /    \ |    |  \\__  \<   |  ||  | |  |/ ___\|  |  \   __\
    /    |    \  |_> >  ___/|   |  \|    `   \/ __ \\___  ||  |_|  / /_/  >   Y  \  |
    \_______  /   __/ \___  >___|  /_______  (____  / ____||____/__\___  /|___|  /__|
            \/|__|        \/     \/        \/     \/\/            /_____/      \/


Hit '<tab>' for a list of available commands
and '[cmd] --help' for help on a specific command.
Hit '<ctrl-d>' or type 'system:shutdown' or 'logout' to shutdown OpenDaylight.

opendaylight-user@root>

Après avoir démarré avec succès, dans la console Karaf installer les features:

• Pour boron

opendaylight-user@root>feature:install odl-dlux-all odl-natapp odl-ovsdb-library odl-restconf-all odl-ovsdb-southbound-api odl-ovsdb-southbound-impl odl-ovsdb-southbound-impl-rest odl-mdsal-all odl-ttp-all

• Pour carbon

opendaylight-user@root>feature:install odl-dluxapps-nodes odl-dluxapps-topologie odl-dluxapps-yangman odl-dluxapps-yangui odl-dluxapps-yangvisualizer odl-dlux-core odl-dluxapps-yangutils odl-ovsdb-library odl-restconf-all odl-ovsdb-southbound-api odl-ovsdb-southbound-impl odl-ovsdb-southbound-impl-rest

Restconf est implémenté dans l'artefact sal-rest-connector, qui est regroupé dans les ensembles/fonctionnalités de Karaf pour une installation facile.

Installer les fonctionnalités Restconf Karaf d'OpenDaylight. On peut afficher les fonctionnalités pertinentes avec feature:list| grep odl-restconf, ou tout installer avec feature:install odl-restconf-all.

Restconf est à l'écoute sur le port 8181 pour les requêtes HTTP. Dans les anciennes versions d'OpenDaylight (Hydrogen, pre-Karaf), Restconf écoutait sur le port 8080.

Restconf peut être démarré en mode débogage via karaf debug. Il est alors possible de se connecter au port 5005 pour le débogage distant. Dans les anciennes versions d'OpenDaylight (Hydrogen, pre-Karaf), Restconf était démarré en mode débogage via karaf -debug et utilisait 8000 comme port de débogage.

OVSDB Southbound Plugin prend en charge la gestion des hôtes OVS via un modèle OVSDB dans MD-SAL qui mappe sur les tables et attributs importants présents dans le schéma Open_vSwitch. Le plug-in OVSDB Southbound est capable de se connecter activement ou passivement à des hôtes OVS et de fonctionner en tant que gestionnaire OVSDB de l'hôte OVS. À l'aide du protocole OVSDB, il est en mesure de gérer la base de données OVS (OVSDB) sur l'hôte OVS, comme défini par le schéma Open_vSwitch.

Dlux est l'interface utilisateur Web d'ODL basé sur Angular JS. Il se compose de deux parties logiques, à savoir,

• odl-dlux-core est un framework qui fournit des fonctionnalités de base, telles que la navigation, l'authentification, etc. Les applications sont construites sur le noyau.

• odl-dluxapps-nodes: affiche la liste des nœuds dans la topologie openflow (flow: 1).
• odl-dluxapps-topologie: application de topologie de base. Affiche les nœuds et les liens de la topologie openflow (flow: 1).
• odl-dluxapps-yangman: interface graphique pour la manipulation des données dans le contrôleur. Génère des formulaires basés sur des modèles Yang chargés. L'utilisateur peut interagir avec le contrôleur sans connaître les modèles Yang, les tester, etc. Remplacement de l'application YangUI.
• odl-dluxapps-yangui: nterface graphique pour la manipulation des données dans le contrôleur.
• odl-dluxapps-yangvisualizer: Visualisation de modèles Yang chargés dans le contrôleur, comme une topologie.
• odl-dluxapps-yangutils: Charge les librairies Yangutils dans Opendaylight

La couche d'abstraction de service dirigée par modèle (MD-SAL), fournit un support commun pour les formats de transport et de charge utile définis par l'utilisateur (par exemple, binaire, XML ou JSON).

MD-SAL utilise YANG comme langage de modélisation pour les définitions d'interface et de données, et fournit un environnement d'exécution basé sur la messagerie et les données pour de tels services basés sur la modélisation YANG.

MD-SAL fournit deux types d'API différents (variantes):

• Liaison MD-SAL: API MD-SAL qui utilisent largement les API et les classes générées à partir de modèles YANG, ce qui offre une sécurité lors de la compilation.
• MD-SAL DOM: API (Document Object Model) qui utilisent une représentation des données semblable à celle du DOM, ce qui les rend plus puissantes, mais offre une sécurité moindre lors de la compilation

Un modèle de type de table (TTP) est un modèle de commutateur abstrait qui décrit les comportements de transfert de commutateur spécifiques d'un programme OpenFlow controller via le protocole OpenFlow-Switch. Lorsque le modèle de transfert peut être implémenté, le contrôleur et le commutateur s’accordent sur un TTP spécifique avant que le contrôleur ne commence à envoyer des messages OpenFlow au commutateur. Cet accord peut être implicite (c'est-à-dire que chaque partie est configurée a priori) ou négocié avant que le transfert ne soit activé.

Les interfaces RESTful de MD-SAL sont conçues sur la base du protocole RESTCONF. Ces interfaces sont générées dynamiquement à l'exécution sur la base des modèles YANG qui les définissent. La génération d'interface étant dynamique, aucune classe Java compilée de manière statique ne peut être annotée pour créer une documentation. L'absence de documentation est l'une des plaintes les plus courantes des utilisateurs de MD-SAL.

L’explorateur d’API RESTCONF doit répondre à cette réclamation et est déployé sous la forme d’un ensemble OSGI qui génère et restitue la documentation au moment de l’exécution.

L'API explorer est accessible à l'addresse:

Http://localhost:8080/apidoc/explorer

ou avec Karaf:

Http://localhost:8181/apidoc/explorer/index.html

La zone de texte URL de la liste de ressources est pré-renseignée avec l'URL Appuyer sur le bouton Explorer pour obtenir la liste.

Une fois que le navigateur a chargé la liste, toute la collection de ressources peut être examinée en la développant (en cliquant dessus).

L'extension d'une collection de ressources liste toutes les ressources supportées. Toute ressource peut être examinée en cliquant dessus.

Les descriptions et les définitions de modèle sont générées à partir de fichiers yang.

Le formulaire HTML est généré par swagger et est basé sur la spécification de déclaration d'API et peut être utilisé pour exécuter l'API et voir la requête/réponse sur le serveur actif .