Mon blog

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 œuvre 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 œuvre 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 œuvre 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. Quant à tcpdump, la gestion de ForCES a été intégrée à partir de la 4.1.1. Vous pouvez voir des exemples en ligne.)

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).

Deux autres RFC sur la mise en œuvre de ForCES sont le RFC 6369 et le RFC 6984, ce dernier rendant compte d'un test d'interopérabilité équivalent, mais plus récent.