3.2.3. IP Statistics Tables
3.2.3. IP Statistics Tables
Les tables de statistiques IP (ipSystemStatsTable et ipIfStatsTable) contiennent des objets pour compter le nombre de datagrammes et d'octets qu'une entité donnée a traités. Contrairement à la tentative précédente, ce document utilise une seule table pour plusieurs types d'adresses. Typiquement, les seuls deux types d'intérêt sont IPv4 et IPv6; cependant, la table peut prendre en charge d'autres types si nécessaire.
La première table, ipSystemStatsTable, transmet des informations à l'échelle du système. (C'est-à-dire que les différents compteurs sont pour toutes les interfaces et non un ensemble spécifique d'interfaces.) Son index est formé à partir d'un seul sous-identifiant qui représente le type d'adresse pour lequel les statistiques ont été comptées.
La deuxième table, ipIfStatsTable, transmet des informations spécifiques à l'interface. Son index est formé à partir de deux sous-identifiants. Le premier représente le type d'adresse (IPv4 et IPv6), et l'interface au sein de ce type d'adresse est représentée par le deuxième sous-identifiant.
Les deux tables ont un ensemble similaire d'objets destinés à compter les mêmes choses, à l'exception de la différence de granularité. L'ID d'objet ipSystemStatsEntry.2 est réservé afin d'aligner les ID d'objets des compteurs de la première table avec leurs homologues de la deuxième table.
Plusieurs objets à noter sont ipSystemStatsDiscontinuityTime, ipIfStatsDiscontinuityTime, ipSystemsStatsRefreshRate et ipIfStatsRefreshRate. Ces objets fournissent des informations sur la ligne de la table plus que sur le système lui-même.
Les objets de discontinuité permettent à une entité de gestion de déterminer si un événement de discontinuité qui invaliderait la compréhension des compteurs par l'entité de gestion s'est produit. Le système étant réinitialisé ou l'interface étant cyclée sont des exemples possibles d'un événement de discontinuité.
Les objets de rafraîchissement permettent à une entité de gestion de déterminer un intervalle de sondage approprié pour le reste des objets.
Le diagramme de cas suivant représente l'ordre général des compteurs de paquets. Afin d'éviter un encombrement supplémentaire, les préfixes "ipSystemStats" et "ipIfStats" ont été supprimés de chacun des noms de compteurs.
from from
interface upper
layers
V V
| |
+ InReceives (1) + OutRequests
| |
| |
+--> InHdrErrors (5) +--> OutNoRoutes
| |
| |
+->-+ InMcastPkts (1) |
| V |
+-<-+ |
| |
+->-+ InBcastPkts (1) |
| V |
+-<-+ |
| |
| |
+--> InTruncatedPkts (5) |
| |
| |
+--> InAddrErrors |
| |
| |
+--> InDiscards (2) |
| |
| |
+--------+------->------+----->-----+----->-----+
| InForwDatagrams (6) | OutForwDatagrams (6)|
| V +->-+ OutFragReqds
| InNoRoutes | | (packets)
/ (local packet (3) | |
| IF is that of the address | +--> OutFragFails
| and may not be the receiving IF) | | (packets)
| | |
| | V OutFragOks
| | | (packets) (7)
| | |
+->-+ ReasmReqds (fragments) +-<-+ OutFragCreates
| | | (fragments)
| | |
| +--> ReasmFails (fragments (4)) +->-+ OutMcastPkts (1)
| | | V
| | +-<-+
+-<-+ ReasmOKs (reassembled packets) |
| +->-+ OutBcastPkts (1)
| | V
+--> InUnknownProtos +-<-+
| |
| |
+--> InDiscards (2) +--> OutDiscards (2)
| |
| |
+ InDelivers + OutTransmits (1)
| |
V V
to to
upper interface
layers
(1) Les compteurs HC et les compteurs d'octets se trouvent également à ces points mais ont été omis pour plus de clarté.
(2) Les compteurs de rejets peuvent s'incrémenter à tout moment dans le chemin de traitement. Les paquets rejetés à gauche de InNoRoutes provoquent l'incrémentation du compteur InDiscards, tandis que ceux rejetés à droite sont comptés dans les compteurs OutDiscards.
(3) Les paquets locaux du côté entrée sont comptés sur l'interface associée à leur adresse de destination, qui peut ne pas être l'interface sur laquelle ils ont été reçus. Cette exigence est causée par la possibilité de perdre l'interface d'origine pendant le traitement, en particulier le réassemblage.
(4) Certains algorithmes de réassemblage peuvent perdre la trace du nombre de fragments pendant le traitement et donc certains fragments peuvent ne pas être comptés dans cet objet.
(5) InTruncatedPkts ne devrait être incrémenté que si la trame contenait un en-tête valide mais était par ailleurs plus courte que requis. Les trames qui sont trop courtes pour contenir un en-tête valide devraient être comptées comme InHdrErrors.
(6) Les objets de transfert peuvent être incrémentés, même pour les paquets qui proviennent localement ou sont destinés à l'hôte local, si leurs adresses sont telles que l'hôte local devrait transférer le paquet pour le transmettre à l'interface correcte.
(7) Lors de la fragmentation d'un paquet, une entité devrait incrémenter le compteur OutFragFails, plutôt que le compteur OutDiscards, afin de préserver l'équation FragOks + FragFails == FragRqds.
Les objets dans les deux tables sont répartis entre plusieurs groupes de conformité en fonction de la bande passante requise pour faire boucler les compteurs en une heure. Le groupe système de base est obligatoire pour toutes les entités. Les autres groupes système sont facultatifs en fonction de la bande passante. Les groupes spécifiques à l'interface sont facultatifs.