B. Claise (Cisco)B. Trammell (ETH Zurich)September20132013-09-16
Le protocole IPFIX d'envoi par un
routeur de résumés statistiques sur le trafic
qu'il voit passer (), dépend d'un modèle de données,
que décrit notre RFC, qui remplace l'ancien .
Le qui normalise le protocole
IPFIX indique comment
transporter les données de l'exporteur
(typiquement un routeur) vers le
récolteur (typiquement la machine
d'administration du réseau) mais
n'indique pas quelles données sont
transportées. Notre RFC va jouer ce rôle, équivalent à celui du
SMI du pour
SNMP.
Notre RFC est assez simple (son prédécesseur, le était très long, mais c'est parce qu'il intégrait la
liste des éléments d'information disponibles, elle est désormais dans un registre IANA). Un élément d'information a un nom (par exemple
destinationTransportPort), une description (cet
élément indique le port de destination du flot), un type
(ici unsigned16, nombre entier sur 16 bits) et d'autres informations utiles comme un ElementID qui
identifie de manière unique un élément d'information. Les types sont décrits en détail dans la section 3 mais sont
très classiques (entiers de différentes factures, booléens, adresses
MAC, chaînes de caractères en
Unicode, etc). Plus originaux sont les sémantiques de la
section 3.2. Si les éléments ont par défaut la sémantique
quantity (ils affichent la valeur
actuellement mesurée), d'autres sont différents, par exemple en indiquant un total (sémantique
d'odomètre). Ainsi, les éléments ayant une
sémantique de totalCounter repartent de zéro
lorsqu'ils ont atteint leur valeur maximale. Ceux ayant la sémantique
identifier ne sont pas des nombres (même quand
leur valeur est numérique, comme les numéros
d'AS) et ne doivent donc pas être additionnés.
Voici un exemple complet, tiré du registre. Certains champs sont obligatoires, comme le nom, la description, le type (ici un entier non
signé de 64 bits) ou l'ElementID (qui peut être un
nombre simple attribué par l'IANA, pour les éléments « officiels »
comme le 85 montré ici, ou bien complété par un
numéro d'organisation pour les autres). D'autres sont facultatifs
comme l'unité (ici, des
octets ; une erreur dans les unités a déjà
entraîné la perte d'une
sonde spatiale). Le nom suit parfois des conventions de nommage
(section 2.3). Par exemple, les éléments dont le nom commence par
post identifient une mesure faite
après un traitement par une
middlebox, par exemple une
traduction d'adresse. Voici l'élément octetTotalCount :
octetTotalCount
Description:
The total number of octets in incoming packets for this Flow at
the Observation Point since the Metering Process
(re-)initialization for this Observation Point. The number of
octets include IP header(s) and IP payload.
Abstract Data Type: unsigned64
Data Type Semantics: totalCounter
ElementId: 85
Status: current
Units: octets
Le vrai format source du registre (regardez depuis autre
chose qu'un navigateur Web) est XML (section 7.3), avec un schéma en Relax NG. La définition ci-dessus est en fait :
octetTotalCountunsigned64flowCountertotalCounter85allcurrent
The total number of octets in incoming packets
for this Flow at the Observation Point since the Metering
Process (re-)initialization for this Observation Point. The
number of octets includes IP header(s) and IP payload.
octets02013-02-18
]]>
Les éléments dans le
registre IANA sont décrits en XML car cela permet de produire automatiquement du code ou
des fichiers de configuration à partir du registre. Mais le protocole
IPFIX lui-même n'utilise pas du tout XML.
Les changements depuis le sont décrits
en section 1.1. Le
principal est que la liste des éléments d'information, au
lieu d'être listée dans le RFC, est désormais dans un registre
IANA. D'autre part, le mécanisme pour modifier cette liste a
été légèrement changé (section 7.4). Il est décrit en détail dans le . En gros, pour ajouter un nouvel élément d'information, il
faut un examen par un expert (le décrit
toutes ces procédures).