http://www.bortzmeyer.org/6053.html
----------------------------
Auteur(s) du RFC: E. Haleplidis (University of Patras), K. Ogawa (NTT
Corporation), W. Wang (Zhejiang Gongshang University), J. Hadi Salim (Mojatatu
Networks)
----------------------------
C'est bien joli de spécifier des protocoles réseau, encore faut-il
qu'ils soient implémentés. Une des raisons pour lesquels les protocoles
de la famille TCP/IP ont battu à plate couture les protocoles ISO,
pourtant soutenus par divers moyens bureaucratiques, est l'accent mis
sur la disponibilité de programmes mettant en oeuvre les spécifications,
les RFC. Ces programmes permettent de vérifier que la norme est
implémentable (contrairement à beaucoup de normes qui sont restés sur
le papier car irréalistes) et que les différentes implémentations
*interopèrent*. Ce RFC 6053 est le rapport décrivant trois mises en
oeuvre du protocole ForCES ("Forwarding and Control Element Separation",
un protocole de communication à l'intérieur d'un routeur, entre ses
divers éléments). Il suit donc les règles et principes du RFC sur les
rapports d'implémentation, le RFC 5657.
Un petit rappel d'abord. ForCES ("Forwarding and Control Element
Separation"), normalisé dans le RFC 5810, définit un modèle (RFC 3746)
où le routeur est composé de *CE* ("Control Element") qui pilotent des
*FE* ("Forwarding Element"). Les CE parlent les protocoles de routage
comme OSPF, les FE font la transmission des paquets. Entre CE et FE,
les messages ForCES peuvent être transmis par plusieurs protocoles, le
plus utilisé (car le seul qui soit obligatoire) étant SCTP-TML
("SCTP-based Transport Mapping Layer") normalisé dans le RFC 5811 et
fondé sur SCTP. (Voir la section 2 pour des rappels plus complets.)
Place aux tests, maintenant. Trois mises en oeuvre indépendantes ont été
testées (section 3) : celle de NTT, celle de l'université de Patras, et
celle de l'université de Zhejiang Gongshang (aucune des trois n'est
distribuée publiquement pour l'instant). Les tests ont été globalement
couronnés de succès, la plupart des bogues ont été corrigées
immédiatement, les manques ayant été identifiés et les programmeurs
ayant promis qu'ils les combleraient bientôt. Le test
d'interopérabilité a été fait en juillet 2009. Les chinois n'étaient
pas présents physiquement sur le lieu du test, ce qui a été l'occasion
de tester ForCES sur une longue distance, et à travers le NAT. Outre
les trois implémentations citées, le test mettait en jeu des
modifications locales de deux analyseurs réseaux répandus, Wireshark et
tcpdump. (Le travail sur Wireshark a été publié dans « "Method and
implementation of building ForCES protocol dissector based on
wireshark" » par Feng Luo, Ligang Dong et Fenggen Jia, à la conférence
"Information Management and Engineering (ICIME), 2010". Le "patch" se
trouve dans la bogue #3534
(https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3534). Quant à
tcpdump, la gestion de ForCES a été intégrée à partir de la 4.1.1. Vous
pouvez voir des exemples en ligne
(http://www.ietf.org/mail-archive/web/forces/current/msg03688.html).)
Comment se fait un tel test d'interopérabilité ? La section 4 résume la
méthodologie suivie. Les développeurs ont d'abord rempli un
questionnaire où ils devaient indiquer quelle étaient les fonctions de
ForCES que leur programme gérait. Les différents programmes ont ensuite
été mis l'un en face =de l'autre dans le labo et ont échangé des
messages. Le bon fonctionnemement a été vérifié à la fois par les
réactions des programmes et par l'examen des "sniffers". Quelques
raccourcis ont été pris (section 5). Par exemple, bien qu'IPsec soit
obligatoire pour SCTP-TML, il n'a pas été testé, en considérant
qu'IPsec était un protocole suffisamment mûr pour qu'on puisse se
dispenser de le tester.
La section 6 donne tous les détails des tests, des messages testés, et
de leurs résultats. Par exemple, un des tests était d'activer le
"heartbeat" (l'envoi de messages réguliers, permettant de vérifier que
le système fonctionne toujours) sur un FE (section 6.1.2.6), puis de
changer l'intervalle d'émission des battements.
On l'a dit, le test a été globalement réussi. Mais il y a eu quelques
petits problèmes, listés dans la section 6.2.3. Par exemple, une
ambiguité est apparue dans la section 4.2.1.2 du RFC 5811 (qui n'était
pas encore publié au moment du test, et qui a finalement été publié en
corrigeant l'ambiguité) quant au niveau de priorité à donner à une
réponse lorsque la question n'avait pas le niveau de priorité standard.
Il y avait aussi de franches bogues, comme le FE et le CE attendant
tous les deux une action et se bloquant mutuellement ou bien comme un
mauvais calcul du champ « longueur » des messages (qui ne doit pas
inclure les bits de remplissage). Il y avait aussi des problèmes qui
n'étaient de la faute, ni de la norme, ni du programme mais qui
reflétaient des limites de ForCES (comme la détection trop lente, dans
certains cas, des coupures de la liaison entre CE et FE : SCTP-TML
n'est pas forcé de réagir en temps réel à une telle coupure).
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
