3.2.3. IP Statistics Tables (IP-Statistiktabellen)
Die IP-Statistiktabellen (ipSystemStatsTable und ipIfStatsTable) enthalten Objekte zum Zählen der Anzahl von Datagrammen und Oktetten, die eine gegebene Entität verarbeitet hat. Im Gegensatz zum vorherigen Versuch verwendet dieses Dokument eine einzige Tabelle für mehrere Adresstypen. Typischerweise sind die einzigen beiden interessanten Typen IPv4 und IPv6; die Tabelle kann jedoch bei Bedarf andere Typen unterstützen.
Die erste Tabelle, ipSystemStatsTable, übermittelt systemweite Informationen. (Das heißt, die verschiedenen Zähler gelten für alle Schnittstellen und nicht für eine bestimmte Gruppe von Schnittstellen.) Ihr Index wird aus einer einzelnen Sub-ID gebildet, die den Adresstyp darstellt, für den die Statistiken gezählt wurden.
Die zweite Tabelle, ipIfStatsTable, übermittelt schnittstellenspezifische Informationen. Ihr Index wird aus zwei Sub-IDs gebildet. Die erste repräsentiert den Adresstyp (IPv4 und IPv6), und die Schnittstelle innerhalb dieses Adresstyps wird durch die zweite Sub-ID repräsentiert.
Die beiden Tabellen haben einen ähnlichen Satz von Objekten, die dazu bestimmt sind, dieselben Dinge zu zählen, mit Ausnahme des Unterschieds in der Granularität. Die Objekt-ID "ipSystemStatsEntry.2" ist reserviert, um die Objekt-IDs der Zähler in der ersten Tabelle mit ihren Gegenstücken in der zweiten Tabelle auszurichten.
Mehrere zu beachtende Objekte sind ipSystemStatsDiscontinuityTime, ipIfStatsDiscontinuityTime, ipSystemsStatsRefreshRate und ipIfStatsRefreshRate. Diese Objekte liefern Informationen über die Zeile in der Tabelle mehr als über das System selbst.
Die Diskontinuitätsobjekte ermöglichen es einer Verwaltungsentität zu bestimmen, ob ein Diskontinuitätsereignis aufgetreten ist, das das Verständnis der Verwaltungsentität über die Zähler ungültig machen würde. Die Neuinitialisierung des Systems oder das Durchlaufen der Schnittstelle sind mögliche Beispiele für ein Diskontinuitätsereignis.
Die Aktualisierungsobjekte ermöglichen es einer Verwaltungsentität, ein geeignetes Abfrageintervall für die restlichen Objekte zu bestimmen.
Das folgende Case-Diagramm stellt die allgemeine Reihenfolge der Paketzähler dar. Um zusätzliche Unordnung zu vermeiden, wurden die Präfixe "ipSystemStats" und "ipIfStats" von jedem Zählernamen entfernt.
von von
Schnittstelle oberen
Schichten
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)
/ (lokales Paket (3) | |
| IF ist das der Adresse | +--> OutFragFails
| und möglicherweise nicht die empfangende 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
zu zur
oberen Schnittstelle
Schichten
(1) Die HC-Zähler und Oktett-Zähler befinden sich ebenfalls an diesen Punkten, wurden jedoch zur Klarheit weggelassen.
(2) Die Verwerfungszähler können zu jedem Zeitpunkt im Verarbeitungspfad inkrementiert werden. Pakete, die links von InNoRoutes verworfen werden, veranlassen den InDiscards-Zähler zu inkrementieren, während diejenigen, die rechts verworfen werden, in den OutDiscards-Zählern gezählt werden.
(3) Lokale Pakete auf der Eingabeseite werden auf der Schnittstelle gezählt, die mit ihrer Zieladresse verbunden ist, was möglicherweise nicht die Schnittstelle ist, auf der sie empfangen wurden. Diese Anforderung wird durch die Möglichkeit verursacht, die ursprüngliche Schnittstelle während der Verarbeitung zu verlieren, insbesondere bei der Reassemblierung.
(4) Einige Reassemblierungs-Algorithmen können während der Verarbeitung die Übersicht über die Anzahl der Fragmente verlieren, sodass einige Fragmente möglicherweise nicht in diesem Objekt gezählt werden.
(5) InTruncatedPkts sollte nur inkrementiert werden, wenn der Frame einen gültigen Header enthielt, aber ansonsten kürzer als erforderlich war. Frames, die zu kurz sind, um einen gültigen Header zu enthalten, sollten als InHdrErrors gezählt werden.
(6) Die Forwarding-Objekte können inkrementiert werden, selbst für Pakete, die lokal entstanden sind oder für den lokalen Host bestimmt sind, wenn ihre Adressen so beschaffen sind, dass der lokale Host das Paket weiterleiten müsste, um es an die richtige Schnittstelle zu übergeben.
(7) Beim Fragmentieren eines Pakets sollte eine Entität den OutFragFails-Zähler inkrementieren, anstatt den OutDiscards-Zähler, um die Gleichung FragOks + FragFails == FragRqds zu bewahren.
Die Objekte in beiden Tabellen sind auf mehrere Konformitätsgruppen verteilt, basierend auf der Bandbreite, die erforderlich ist, um die Zähler innerhalb einer Stunde zu umwickeln. Die Basissystemgruppe ist für alle Entitäten obligatorisch. Die anderen Systemgruppen sind je nach Bandbreite optional. Die schnittstellenspezifischen Gruppen sind optional.