Ce RFC est l'un de ceux du
groupe de travail IETF nommé LMAP, pour
« Large-Scale Measurement Platforms ». Ce groupe
développe des normes pour les systèmes de mesure à grande échelle,
ceux où des centaines ou des milliers de sondes quantifient
l'Internet. Il décrit le modèle de données utilisé.
Le projet LMAP est décrit dans les RFC 7536 (qui explique à quoi sert LMAP, avec deux exemples concrets) et RFC 7594 (qui normalise le vocabulaire et le cadre général). Pour résumer très vite, LMAP prévoit un
Measurement Agent (la sonde) qui parle à un
contrôleur, qui lui dit quoi faire, et à un
collecteur, qui ramasse les données. Ce nouveau
RFC décrit le modèle de données abstrait utilisé dans ces deux
communications.
Rappelons que, dans le cadre défini pour LMAP, chaque MA
(Measurement Agent) parle à un et un seul
contrôleur, qui lui dit ce qu'il doit mesurer. (LMAP sépare le
rôle du contrôleur et du collecteur, rôles que beaucoup de
systèmes déployés fusionnent.) Il y a donc trois protocoles en
jeu, le protocole de contrôle, entre le contrôleur et les MA, le
protocole de collecte, entre les collecteurs et les MA, et enfin
les protocoles utilisés dans les tests
(ICMP ECHO, par exemple, mais aussi
HTTP, DNS…) Enfin,
il y a aussi la configuration nécessaire dans tous ces
équipements. Tous ces points peuvent faire l'objet d'un travail de
normalisation, mais ce RFC 8193 présente uniquement
un modèle de données adapté au protocole de collecte et au
protocole de contrôle.
La notion de modèle de données est expliquée dans le RFC 3444. En gros, il s'agit d'un modèle
abstrait (très abstrait) décrivant quel genre de données sont échangées. Il peut
se formaliser de manière un peu plus concrète par la suite, par
exemple en utilisant le langage YANG (c'est
justement ce que fait le RFC d'accompagnement, le RFC 8194). Un
tel modèle sert à guider la normalisation, à faciliter la
traduction d'un protocole dans un autre s'ils utilisent le même
modèle de données, et à définir les données que doit mesurer et
conserver le MA.
Le modèle défini ici utilise une notation formelle, utilisant
des types de données classiques en programmation (section 3 du RFC) :
int (un entier),
boolean (une valeur
logique), string, mais aussi des
types plus riches comme datetime ou uri.
Le modèle lui-même est dans la section 4 du RFC. Je rappelle
qu'il suit le cadre du RFC 7594. Il a six
parties :
- Informations de pré-configuration du MA (celle qui est
faite en usine),
- Informations de configuration du MA,
- Instructions reçues par le MA (« envoie telle requête
DNS à tel serveur, de telle heure à telle
heure »),
- Journal du MA, avec des évènements
comme le redémarrage de la sonde,
- État général du MA (« je sais faire des tests
IPv6 »),
- Et bien sûr, le résultat des mesures, ce qui est
l'information la plus importante.
Le MA peut également avoir d'autres informations, par exemple des
détails sur son type de connectivité.
Pour donner des exemples concrets, je vais souvent citer les
sondes RIPE
Atlas, même si ce système, conçu avant le RFC, ne suis pas
exactement ce modèle. C'est sans doute l'un des plus grands, voire le plus
grand réseau de points de mesure dans le monde, avec près de
10 000 sondes connectées. Par exemple, pour la configuration, les
informations de pré-configuration d'une sonde Atlas comprennent
une adresse MAC et un identificateur, qu'on
peut voir sur la sonde :
Les sondes sont également pré-configurées avec le nom du
contrôleur (qui sert également de collecteur). Elles acquièrent le
reste de leur configuration par
DHCP et SLAAC. Regardons par exemple la sonde
d'identificateur #21660, installée à
Cochabamba, on voit les adresses IP obtenues :
Les sondes Atlas disposent également d'étiquettes
(tags) décrivant plus précisement certaines de
leurs caractéristiques. Certaines des étiquettes sont attribuées
manuellement par leur propriétaire (en bleu sur l'image ci-dessous), d'autres, qui peuvent être
déterminées automatiquement, sont mises par le système (en vert
sur l'image), et rentrent donc dans le cadre de la partie « état
général de la sonde » du modèle :
Les classes utilisées dans le modèle
sont, entre autres :
- Les agendas (schedules) qui indiquent
quelle tâche doit être accomplie,
- Les canaux de communication (channels),
- les configurations (task
configurations),
- Les évènements (events), qui détaillent
le moment où une tâche doit être exécutée.
Première partie, la pré-configuration (section 4.1). On y trouve les
informations dont le MA aura besoin pour accomplir sa mission. Au
minimum, il y aura un identificateur (par exemple
l'adresse MAC), les coordonnées de son
contrôleur (par exemple un nom de
domaine, mais le RFC ne cite que le cas où ces
coordonnées sont un URL, pour les
protocoles de contrôle de type REST),
peut-être des moyens d'authentification
(comme le certificat de
l'AC qui signera le certificat du
contrôleur). URL et moyens d'authentification, ensemble, forment
un canal de communication.
Dans le langage formel de ce modèle, cela fait :
object {
[uuid ma-preconfig-agent-id;]
ma-task-obj ma-preconfig-control-tasks<1..*>;
ma-channel-obj ma-preconfig-control-channels<1..*>;
ma-schedule-obj ma-preconfig-control-schedules<1..*>;
[uri ma-preconfig-device-id;]
credentials ma-preconfig-credentials;
} ma-preconfig-obj;
Cela se lit ainsi : l'information de pré-configuration (type
ma-preconfig-obj) comprend
divers attributs dont un identificateur (qui est un
UUID, on a vu que les Atlas utilisaient un
autre type d'identificateurs), des canaux de communication avec le
contrôleur, et des lettres de créance à présenter pour
s'authentifier. Notez que l'identificateur est optionnel (entre
crochets).
Vous avez compris le principe ? On peut passer à la suite plus
rapidement (je ne vais pas répéter les déclarations formelles,
voyez le RFC). La configuration (section 4.2) stocke les
informations volatiles (la pré-configuration étant consacrée aux
informations plus stables, typiquement stockées sur une mémoire
permanente).
Les instructions (section 4.3) sont les tâches que va accomplir
la sonde, ainsi que l'agenda d'exécution, et bien sûr les canaux
utilisé pour transmettre les résultats. La
journalisation (section 4.4) permet
d'enregistrer les problèmes (« mon résolveur
DNS ne marche plus ») ou les évènements
(« le courant a été coupé »).
Il ne sert évidemment à rien de faire des mesures si on ne
transmet pas le résultat. D'où la section 4.6, sur la transmission
des résultats de mesure au collecteur. La communication se fait
via les canaux décrits en section 4.8.
Une dernière photo, pour clore cet article, une sonde RIPE
Atlas en fonctionnement, et une autre sonde, la SamKnows :
Merci à André Sintzoff pour avoir trouvé de grosses fautes.
