W. Wang (Zhejiang Gongshang University)K. Ogawa (NTT Corporation)E.H. Haleplidis (University of Patras)M. Gao (Hangzhou BAUD Networks)J. Hadi Salim (Mojatatu Networks)August20132013-08-25
Un élément essentiel de la culture IETF est
l'importance donnée aux programmes qui marchent : rough
consensus and running code. D'où les fréquents tests
d'interopérabilité, entre diverses mises en œuvre
des protocoles IETF, afin de vérifier que, non seulement le code
tourne mais qu'il peut interagir avec d'autres instances. Le groupe de travail ForCES,
qui normalise des protocoles de communication
internes aux routeurs, a ainsi procédé à deux ateliers
de tests d'interopérabilité, ce RFC documentant
le second.
Le premier avait eu lieu en 2009 à
l'université de Patras et avait été
documenté dans le . Le second a eu lieu
en février 2011 à l'ITL (Internet
Technology Lab) à l'université de Zhejiang
Gongshang. (Oui, je sais, c'est long, entre l'atelier et la
publication du compte-rendu dans un RFC...)
Rappelons ce que fait ForCES : il normalise la communication entre
les éléments d'un routeur (ou autre engin du
réseau : la norme parle de NE pour
Network Element). Le but est de permettra la
construction de routeurs en kit, en assemblant des parties d'origines
différentes, mais parlant toutes ForCES. Le système ForCES est riche
et complexe et cet atelier d'interopérabilité testait cinq
composants : le protocole de communication entre
CE (Control Element) et
FE (Forwarding Element),
normalisé dans le , le protocole de
transport sous-jacent (), le modèle des FE
(), la bibliothèque standard () et le mécanisme de haute disponibilité (dont le RFC n'a pas encore été publié). Des CE et FE d'origines diverses ont été
connectés entre eux, se sont parlé, la bonne compréhension a été
vérifiée et tcpdump et
Wireshark ont été utilisés pour un contrôle supplémentaire.
Trois mises en œuvre de ForCES ont été testées, les mêmes qu'à
l'atelier précédent (ForCES n'a pas pour l'instant suscité un intérêt
massif) : celle de
NTT, celle de l'université de
Patras, et celle faite en commun entre l'université de
Zhejiang
Gongshang et la société BAUD Network. Les Grecs n'ayant pu
se déplacer, ils ont participé aux tests à distance, connectés via un
VPN (dans la réalité, bien sûr, les FE et les
CE seront toujours proches, souvent dans le même boîtier physique). Globalement, les
tests ont été des succès, à part un problème embêtant avec
l'encapsulation des données dans une réponse ForCES (voir les détails
plus loin). Comme toujours, ces tests ont permis de découvrir des
erreurs ou des approximations dans les RFC.
Les communications utilisaient IPsec,
puisque le RFC sur le transport de ForCES, , fait obligation à chaque mise en œuvre de ForCES
d'avoir IPsec (mais pas forcément de l'activer par défaut : c'est sa
disponibilité qui est obligatoire, pas son usage).
Un exemple d'un des scénarios testés (section 3.4) : deux machines terminales sur
deux réseaux locaux différents étaient connectées via deux routeurs
OSPF. L'un était un routeur classique, l'autre
une machine ForCES dont le CE (Control Element)
parlait OSPF avec le routeur classique pendant que le FE
(Forwarding Element) transmettait les paquets. Ce
scénario nécessitait que le CE communique au FE les règles qu'il avait
apprises en OSPF et testait la mise en œuvre correcte de plusieurs
fonctions du . Une variante de ce test
remplaçait le routeur classique par une autre machine ForCES : les
deux CE se parlaient en OSPF et chacun disait ensuite à son FE ce
qu'il devait faire des paquets IP.
La section 4 donne les résultats complets des tests. Il y a une
très grande majorité de succès mais aussi deux échecs, qui vont
nécessiter du travail chez les programmeurs.
Mais le principal problème de l'atelier a été un problème lors de
la communication de tableaux (et pas de simples valeurs scalaires)
entre deux programmes. Le problème est que ForCES permet plusieurs
encodages possibles pour les données complexes (, section 6 et notamment 6.4). La règle est que chaque
élément ForCES peut choisir librement parmi ces encodages (pas moins
de trois possibilités légales, dans l'exemple discuté dans la section
5 de notre RFC). Mais un
programme considérait que la réponse venait forcément dans l'encodage
de la question, et plantait si ce n'était pas le cas. Bien qu'il soit
clairement en tort, notre RFC considère qu'il vaut mieux en effet
générer une réponse en utilisant le même encodage que la question ou
la commande. Personnellement, je pense plutôt que c'était très gentil
de donner un vaste choix aux CE et FE (par exemple pour optimiser le
cas de grands tableaux ayant beaucoup de vide) mais que cela mène
forcément à ce genre de problèmes. Traditionnellement, les protocoles
IETF préfèrent l'interopérabilité à la liberté et ForCES était
peut-être allé trop loin dans les possibilités de choix.