Traduit de Anglais vers Français - www.onlinedoctranslator.
com
Application de chaînage de fonctions de service pour le contrôleur Ryu SDN
Introduction
Ce projet est un prototype d'application Service Function Chaining (SFC) écrite en Python pour le
contrôleur Ryu SDN. Il utilise le réseau plat, qui peut être référencé comme domaine compatible
SFC. La seule fonction exécutée par les fonctions de service (que je peux appeler fonctions de
réseau virtuel) est la transmission ultérieure du trafic. Donc, ces VNF référencés ici en tant que
transitaires.
L'application applique des règles de transfert pour un flux particulier vers un réseau
compatible OpenFlow afin que le trafic passe par la chaîne définie de fonctions de service.
Avis de désordre terminologique
Plusieurs organisations travaillent à la promotion du SDN et du NFV. L'Internet Engineering Task Force, le
groupe de travail sur le chaînage des fonctions de service (IETF WG SFC) et l'Institut européen des normes
de télécommunications, le groupe de spécification industrielle pour NFV (ETSI ISG NFV) sont deux à
mentionner. Ils ont tendance à appeler les mêmes choses avec des termes différents. Lorsque l'IETF
appelle un chemin prévu qu'un flux traverse en tant queChaîne de fonctions de service, ETSI fait
référence à la même chose comme unGraphique de transfert. La même chose concerne un Fonction de
service(IETF) et(Fonction réseau virtuel)(IETF) qui sont une instance de quelque chose qui traite les flux de
données. Ces termes sont donc choisis parmi les deux organismes de normalisation et utilisés ici de
manière interchangeable. Bien que pour VNF il ne soit pas très important de souligner son caractère
virtuel dans ce projet, j'utilise largement l'acronyme VNFici.
Comment ça fonctionne
Un graphique de transfert de fonction réseau définit une séquence de NF traversés par les paquets.
VNF Forwarding Graph fournit la connectivité logique entre les VNF. L'application contrôleur lit dans
le catalogue de services une description d'un service destiné à un flux de paquets généré par un
locataire. La description du service est fournie par OSS/BSS ou manuellement dans l'environnement
de test. C'est censé être une liste de VNF. Ces informations ainsi que la description VNF sont
suffisantes pour formuler et appliquer les règles Open Flow sur le réseau. Graphiques réels obtenus
grâce à la manipulation des informations d'adresse dans les en-têtes de paquets, suivie du transfert
des paquets.
Auto-inscription VNF
L'auto-enregistrement VNF est un mécanisme de découverte de fonctions de service.
Une approche bovine implique qu'un service soit instancié à partir d'un pool de ressources
englobant les ressources informatiques, de stockage et de réseau. Le gestionnaire d'infrastructure
virtuelle est responsable de la planification et du démarrage d'une machine virtuelle. Dans ce cas,
l'emplacement d'un service (nous l'appellerons fonction de service) est connu avec la granularité de
l'emplacement du pool de ressources, ce qui n'est pas suffisant pour la construction du Forwarding
Graph. Pour relever ce défi, nous présentons une fonctionnalité d'auto-enregistrement qui permet à
un service d'annoncer sa présence dans le réseau. Un processus assistant sur la VM émet un
message d'enregistrement au réseau au nom du service. Ce message contient des informations
descriptives sur le type de service dont il s'agit, le rôle que joue l'interface émettrice (entrée, sortie,
entrée-sortie), si le service est bidirectionnel ou asymétrique, etc. Le service lui-même ne dispose
cependant pas de toutes les informations nécessaires. C’est là qu’intervient un commutateur
compatible Open Flow.
Il enveloppe le paquet d'enregistrement dans un message packet_in OpenFlow et l'envoie au contrôleur
SDN. Le message Packet_in comprend des informations spécifiques au réseau, telles que le localisateur
d'adresse de service, qui est son adresse MAC, l'identifiant de chemin de données qui est un identifiant de
commutateur unique et un identifiant de port, via lequel le message d'enregistrement a été reçu.
L'application de contrôle analyse le message packet_in, en récupère les informations, décapsule le
message d'enregistrement, le décode également et transmet toutes les informations récupérées à la base
de données.
Application des règles
Dans la configuration, nous avons un réseau SDN contrôlé par un contrôleur SDN sur lequel une
application SFC est exécutée. L'application expose l'API REST pour accepter les directives du système
OSS/BSS. L'application est intégrée à la base de données, où sont stockées les informations sur les
fonctions de service, les services et les flux enregistrés. Cette base de données représente un
catalogue de services. Il n'y a pas de système OSS/BSS (je vais donc jouer un rôle de système OSS/
BSS), de définitions de service et de flux vers les liaisons de service préparées manuellement ainsi
que l'envoi de requêtes aux API REST de l'application.
Le processus se déroule comme ceci :
1. Découverte SF : auto-enregistrement VNF. La table DB la plus à droite (voir photo) est remplie avec les
caractéristiques VNF.
2. OSS/BSS remplit les tables de base de données décrivant le service et la liaison flux-service, où la
spécification du flux est incluse.
3. OSS/BSS demande de démarrer SFC pour un flux. Le flux est référencé par ID.
4. L'application SFC interroge la base de données sur la spécification de flux...
5. ... et installe la règle de capture sur le réseau. On suppose que le point d’entrée du flux
n’est pas connu.
6. Dès que le trafic qui vous intéresse apparaît dans le domaine compatible SFC, l'événement est
signalé à l'application SFC. A ce moment, le point d'entrée est révélé.
7. La règle de capture est supprimée et la règle de direction est installée le long du chemin de la chaîne de service.
8. La circulation est dirigée.
L'application peut être améliorée en ajoutant la prise en charge des fonctionnalités suivantes :
9.Prise en charge des types d'interface. Actuellement, toutes les interfaces sont traitées comme du type inout.
L'affinement des requêtes vers la base de données du catalogue de services permettra d'implémenter une
fonction de service multi-hébergé avec une direction de flux définie (ex. Pare-feu avec interfaces internes et
externes).[FAIT]
dix.La prise en charge du flux symétrique peut être une fonctionnalité pratique pour ajouter automatiquement un
graphique de transfert inverse via des fonctions de service symétriques. Les fonctions symétriques ou
bidirectionnelles sont celles qui nécessitent que le trafic soit acheminé dans les deux sens : liaison montante et
liaison descendante afin que le service puisse être fourni (exemple : NAT). Ne pas disposer de cette fonctionnalité
n'est pas critique, mais nécessite une définition explicite du graphique de transfert inverse.[FAIT]
11. Le support de groupe est requis lorsque plusieurs instances d'une fonction de service sont
déployées. Son absence peut être contournée en utilisant des équilibreurs de charge devant les
fonctions réseau réelles.
12. Etc. : Un ensemble plus riche de champs de protocole, une logique générique, des statuts VNF et
d'autres améliorations.
Installation
Initialement, l'environnement était basé sur Ubuntu 14.04. Récemment, il a été testé sur la dernière
version d'Ubuntu 20.04 LTS. Je suppose que d'autres Linux conviennent également, même si je ne les
ai pas essayés. Le logiciel suivant doit être installé. Des instructions d'installation détaillées pour
chacun des composants sont disponibles sur les pages Web associées.
Contrôleur Ryu
https://github.com/osrg/ryu
Pour éviter les erreurs lors de l'exécution de l'application Ryu, installez l'ancienne version de l'eventlet :
pip install eventlet==0.30.2
Mininet
http://mininet.org/download/
Navigateur SQLite
En fait, tant qu'il existe un client SQLite, celui-ci n'est pas obligatoire, mais j'ai trouvé l'outil très
pratique pour vérifier et éditer la base de données SQLite. La base de données est utilisée dans le
projet en tant qu'annuaire de services.
http://sqlitebrowser.org/
Environnement de démonstration
Mon environnement de démonstration est basé sur mininet, un émulateur réseau qui crée un réseau
d'hôtes virtuels, de commutateurs, de contrôleurs et de liens. Les commutateurs utilisés dans la
démonstration sont des OpenvSwitches. Par souci de simplicité, l'environnement de démonstration se
compose de cinq commutateurs connectés linéairement ; cinq hôtes, chacun lié à un commutateur, à
l'exception de h2 et h3 qui ont respectivement des liens supplémentaires vers les commutateurs s3 et s4,
et un contrôleur Ryu exécutant OpenFlow1.3. Le script example.py configure l'environnement (voir les
instructions de démonstration). Dans l'environnement, les hôtes
h2 et h3 sont des VNF avec deux interfaces. Ces interfaces sont chacune de type « in » ou « out ». Le
type « inout » est également pris en charge.
Le trafic provient de h1 vers h5 et passe par h2 et h3 selon une description de service lorsque des
règles de flux sont imposées au réseau. Pour exécuter la démonstration en douceur, assurez-vous
que le transfert IP est activé sur le système d'exploitation (sudo sysctl net.ipv4.ip_forward=1),
tracerouteest installé et les lignes suivantes sont ajoutées à /etc/hosts :
10.0.0.1h1
10.0.0.2 h2 pouces
10.0.0.3 h3-dans
10.0.0.4h4
10.0.0.5h5
10.0.0.12 h2-sortie
10.0.0.13 sortie h3
La démonstration peut également être lancée sur les conteneurs Docker. Voir les
instructionsici.
Instructions de démonstration
La démonstration inclut un tableau de flux prérempli dans la base de données, qui peut bien
entendu être modifié. Le flux 3 est utilisé ici, dont la spécification décrit un flux de h1 (10.0.0.1) à
h5 (10.0.0.5). Le script example.py fait toute la magie de l'exécution du mininet, de
l'interconnexion des hôtes et de l'auto-enregistrement sur eux.
13. Ouvrez quatre terminaux
14. Démarrez l'application Ryu dans le 1er terminal :
• 1ère borne :ryu-manager --verbose ./sfc_app.py
15. Démarrez la topologie de test dans le 2ème terminal :
• 2ème borne :sudo ./exemple.py
16. Vérifiez les règles OpenFlow par défaut avant l'application de SFC :
• 2ème borne :mininet> h1 traceroute -I h5
• 4ème borne :pour je dans {1..5} ; faire echo s$i; sudo ovs-ofctl -O OpenFlow13 dump-flows s$i ; fait
• Un saut est visible, les règles par défaut sont installées
17. Appliquez la chaîne de fonctions de service et vérifiez les règles de capture installées sur les commutateurs OF :
• 3ème borne :boucle -vhttp://127.0.0.1:8080/add_flow/3
• 4ème borne :pour je dans {1..5} ; faire echo s$i; sudo ovs-ofctl -O OpenFlow13 dump-flows s$i ; fait
• Après l'application du flux, les règles de capture pour les deux directions sont visibles sur le commutateur OF. Le flux 3
contient un VNF bidirectionnel.
18. Démarrez la circulation, vérifiez les règles de direction :
• 2ème borne :mininet> h1 traceroute -I h5
• 4ème borne :pour je dans {1..5} ; faire echo s$i; sudo ovs-ofctl -O OpenFlow13 dump-flows s$i ; fait
• Désormais, le trafic franchit plusieurs sauts, une règle de capture a été remplacée par une règle de
direction.
19. Vérifiez la circulation en sens inverse, vérifiez les règles de direction :
• 2ème borne :mininet> h5 traceroute -I h1
• Le flux de trafic inverse traverse plusieurs sauts car l'une des VNF est bidirectionnelle.
20. Supprimer les flux
• 3ème borne :boucle -vhttp://127.0.0.1:8080/delete_flow/3
• 2ème borne :mininet> h1 traceroute -I h5
• 4ème borne :pour je dans {1..5} ; faire echo s$i; sudo ovs-ofctl -O OpenFlow13 dump-flows s$i ; fait
• Le flux de données passe à nouveau d'un saut, aucune règle associée n'est visible sur le commutateur OF
21. Appliquez la chaîne de fonctions de service et vérifiez les règles de capture installées sur les commutateurs OF :
• 3ème borne :boucle -vhttp://127.0.0.1:8080/add_flow/4
• 4ème borne :pour je dans {1..5} ; faire echo s$i; sudo ovs-ofctl -O OpenFlow13 dump-flows s$i ; fait
• Après l'application du flux, une règle de capture est visible sur le commutateur OF. Flow 4 ne contient pas
de VNF bidirectionnel.
22. Démarrez la circulation, vérifiez les règles de direction :
• 2ème borne :mininet> h1 traceroute -I h4
• 2ème borne :mininet> h4 traceroute -I h1
• 4ème borne :pour je dans {1..5} ; faire echo s$i; sudo ovs-ofctl -O OpenFlow13 dump-flows s$i ; fait
• Désormais, le trafic passe plusieurs sauts de h1 à h4, une règle de capture a été remplacée par une règle
de direction. Le trafic de h4 à h1 passe toujours par un saut car il n’y a pas de VNF bidirectionnelles sur le
chemin.
23. Supprimer les flux
• 3ème borne :boucle -vhttp://127.0.0.1:8080/delete_flow/4
• 2ème borne :mininet> h1 traceroute -I h4
• 4ème borne :pour je dans {1..5} ; faire echo s$i; sudo ovs-ofctl -O OpenFlow13 dump-flows s$i ; fait
• Le flux de données passe à nouveau d'un saut, aucune règle associée n'est visible sur le commutateur OF
