inlinetoc

Il est parfois nécessaire que les architectes de réseau (ou les développeurs comme vous) définissent le comportement de leurs réseaux de manière personnalisée. Par exemple, l'architecte peut vouloir un commutateur réseau lui permettant de contrôler la manière dont les paquets sont routés ou même de définir un protocole personnalisé.

Historiquement, cela était possible via un matériel propriétaire fermé qui peut être extrêmement coûteux ou impossible à obtenir par les chercheurs et les expérimentateurs. Pourtant, cette fonctionnalité est nécessaire pour exécuter des projets à grande échelle mettant en œuvre de nouveaux protocoles expérimentaux, voire des règles de routage pour les besoins de l’architecture réseau de base.

OpenFlow est un standard ouvert géré par Open Networking Foundation. Il spécifie un protocole via un commutateur qu'un contrôleur distant peut modifier le comportement des périphériques réseau via un «jeu d'instructions de transmission» bien défini.

Un commutateur OpenFlow est contrôlé par un contrôleur OpenFlow. Un contrôleur OpenFlow est simplement un progiciel qui s'interface avec le commutateur via l'API OpenFlow et applique des règles de routage.

Chaque entrée de flux de données openflow est principalement définie par:

• un objet Match qui spécifie les paquets faisant partie du flux,
• un objet Actions qui peut exécuter des actions sur les ID de port, les ID de file d'attente (Queue) et jusqu'à 4 protocoles.

Le plus simple moyen de coder des instructions avec openflow dans un commutateur est d'utiliser l'API REST fournit en standard par les contrôleurs.

L'outil CURL permet d'utiliser facilement les APIs REST, par exemple pour pousser (PUT) un objet flow dans la configuration d'un commutateur avec opendaylight, on peut soumettre la requète suivante :

curl --noproxy x.x.x.x -u admin:admin -H 'Content-Type: application/yang.data+xml' -X PUT -d ' \
<strict>false</strict> <flow-name>arp2cntrler</flow-name> <id>37</id> \
<cookie_mask>255</cookie_mask> <cookie>105</cookie> <table_id>0</table_id> \
<priority>1</priority> <hard-timeout>0</hard-timeout> <idle-timeout>0</idle-timeout> \
<match> <ethernet-match> <ethernet-type> <type>2054</type> </ethernet-type> </ethernet-match> \
</match> <instructions> <instruction> <order>0</order> <apply-actions> <action> <order>0</order> \
<output-action> <output-node-connector>openflow:506043239089955:33</output-node-connector> \
<max-length>65535</max-length> </output-action> </action> </apply-actions> </instruction> \
</instructions> </flow>' 'http://xx.xx.xxx.xx:8181/restconf/config/opendaylight-inventory:nodes\
/node/openflow:506043239089955/table/0/flow/37'

SI on détaille la commande celle-ci se compose d'un message (en syntaxe xml) que l'on pousse (PUT) vers une URl

Se compose (e sus de l'adresse du commutateur et du port d'accès à l'API:

Réprésente le chemin d'accès relatif à la fonction, par exemple pour pousser un flux:

• avec opendaylight il faut faire un PUT sur /restconf/config/opendaylight-inventory:nodes/node/
• avec ryu il faut faire un PUT sur /stats/flowentry/add
• avec floodlight il faut faire un PUT sur /wm/staticflowentrypusher/json

Afin d'identifier précisèment un flux le groupe switch(DPID)+table+flux est requis:

• Le DatapathID (DPID) indique sur quel commutateur on veut insérer ce flux.
• L'id du flux doit être unique, Il ne peut y avoir d'autre flux dans la topologie avec le même id.
• table_id Indique dans quelle table le flux doit être recherché/implémenté.

Se décompose en au moins trois objets

L'id du flux doit être unique, Il ne peut y avoir d'autre flux dans la topologie avec le même id.

Indique dans quelle table le flux doit être recherché/implémenté.

Lorsqu'un paquet atteint un commutateur, il parcourt chaque flux en ordre de priorité jusqu'à ce qu'il corresponde à l'un d'entre eux.

L'objet Match spécifie les paquets faisant partie du flux, sous la forme d'un ensemble de champs de paquet à comparer et de leurs valeurs attendues. La norme OpenFlow spécifie l'ensemble des champs de paquet pouvant être mis en correspondance, au niveau des couches 2 (Ethernet), 3 (IP, ARP) et 4 (ICMP, TCP, UDP).

Il est important de noter que la prise en charge des actions comme Ethernet, IPv4, TCP et UDP est facultative. Un contrôleur saura uniquement si un commutateur prend en charge ces actions facultatives basées sur un FeatureRes. Action_capabilities indiquera quelles actions sont supportées par un commutateur. Les actions sont installées en tant qu'ensemble d'actions, qui fait partie d'un message FlowMod.