3.2.3. IP Statistics Tables (Tabelle di Statistiche IP)
3.2.3. IP Statistics Tables (Tabelle di Statistiche IP)
Le tabelle di statistiche IP (ipSystemStatsTable e ipIfStatsTable) contengono oggetti per contare il numero di datagrammi e ottetti che una data entità ha elaborato. A differenza del tentativo precedente, questo documento utilizza una singola tabella per più tipi di indirizzo. Tipicamente gli unici due tipi di interesse sono IPv4 e IPv6; tuttavia, la tabella può supportare altri tipi se necessario.
La prima tabella, ipSystemStatsTable, trasmette informazioni a livello di sistema. (Cioè, i vari contatori sono per tutte le interfacce e non per un insieme specifico di interfacce.) Il suo indice è formato da un singolo sub-id che rappresenta il tipo di indirizzo per il quale sono state contate le statistiche.
La seconda tabella, ipIfStatsTable, trasmette informazioni specifiche dell'interfaccia. Il suo indice è formato da due sub-id. Il primo rappresenta il tipo di indirizzo (IPv4 e IPv6), e l'interfaccia all'interno di quel tipo di indirizzo è rappresentata dal secondo sub-id.
Le due tabelle hanno un insieme simile di oggetti che sono destinati a contare le stesse cose, tranne che per la differenza in granularità. L'object ID "ipSystemStatsEntry.2" è riservato al fine di allineare gli object ID dei contatori nella prima tabella con le loro controparti nella seconda tabella.
Diversi oggetti da notare sono ipSystemStatsDiscontinuityTime, ipIfStatsDiscontinuityTime, ipSystemsStatsRefreshRate e ipIfStatsRefreshRate. Questi oggetti forniscono informazioni sulla riga nella tabella più che sul sistema stesso.
Gli oggetti di discontinuità consentono a un'entità di gestione di determinare se si è verificato un evento di discontinuità che invaliderebbe la comprensione dei contatori da parte dell'entità di gestione. La reinizializzazione del sistema o il ciclo dell'interfaccia sono possibili esempi di un evento di discontinuità.
Gli oggetti di refresh consentono a un'entità di gestione di determinare un intervallo di polling appropriato per il resto degli oggetti.
Il seguente diagramma Case rappresenta l'ordinamento generale dei contatori di pacchetti. Per evitare confusione extra, i prefissi "ipSystemStats" e "ipIfStats" sono stati rimossi da ciascuno dei nomi dei contatori.
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) I contatori HC e i contatori di ottetti si trovano anche in questi punti ma sono stati omessi per chiarezza.
(2) I contatori di scarto possono incrementare in qualsiasi momento nel percorso di elaborazione. I pacchetti scartati a sinistra di InNoRoutes causano l'incremento del contatore InDiscards, mentre quelli scartati a destra sono contati nei contatori OutDiscards.
(3) I pacchetti locali sul lato di input sono contati sull'interfaccia associata al loro indirizzo di destinazione, che potrebbe non essere l'interfaccia su cui sono stati ricevuti. Questo requisito è causato dalla possibilità di perdere l'interfaccia originale durante l'elaborazione, specialmente il riassemblaggio.
(4) Alcuni algoritmi di riassemblaggio possono perdere traccia del numero di frammenti durante l'elaborazione e quindi alcuni frammenti potrebbero non essere contati in questo oggetto.
(5) InTruncatedPkts dovrebbe essere incrementato solo se il frame conteneva un'intestazione valida ma era altrimenti più corto del richiesto. I frame che sono troppo corti per contenere un'intestazione valida dovrebbero essere contati come InHdrErrors.
(6) Gli oggetti di forwarding possono essere incrementati, anche per i pacchetti che hanno avuto origine localmente o sono destinati all'host locale, se i loro indirizzi sono tali che l'host locale dovrebbe inoltrare il pacchetto per passarlo all'interfaccia corretta.
(7) Quando si frammenta un pacchetto, un'entità dovrebbe incrementare il contatore OutFragFails, piuttosto che il contatore OutDiscards, al fine di preservare l'equazione FragOks + FragFails == FragRqds.
Gli oggetti in entrambe le tabelle sono distribuiti tra diversi gruppi di conformità in base alla larghezza di banda richiesta per avvolgere i contatori entro un'ora. Il gruppo di sistema di base è obbligatorio per tutte le entità. Gli altri gruppi di sistema sono opzionali a seconda della larghezza di banda. I gruppi specifici dell'interfaccia sono opzionali.