4. Specifica del protocollo

4.1. Costrutti comuni

Tutti i PDU SNMP sono costruiti utilizzando la struttura ASN.1 definita nella sezione 3.

Il request-id viene utilizzato per distinguere tra le richieste in sospeso e dall'entità SNMP che supporta applicazioni di risponditore di comandi per generare il campo request-id di un Response-PDU. Utilizzando il request-id, un'entità SNMP che supporta applicazioni di generatore di comandi può correlare i Response-PDU in arrivo con le richieste in sospeso, anche quando più richieste alla stessa entità SNMP sono in sospeso contemporaneamente. Nei casi in cui viene utilizzato un servizio di trasporto inaffidabile, lo stesso request-id può essere utilizzato per le ritrasmissioni della stessa richiesta, ma questo non è obbligatorio. Il valore di request-id non deve essere sequenziale e le implementazioni devono fare attenzione a non ripetere un valore recentemente utilizzato per request-id, poiché la richiesta precedente potrebbe essere stata ricevuta ma la risposta persa.

Il componente variable-bindings di tutti i PDU è un elenco di binding di variabili. Quando un PDU viene inviato da un'applicazione di generatore di comandi, questo elenco rappresenta le informazioni di gestione richieste o i comandi dati. Nel caso di risposte a operazioni di recupero e modifica, questo elenco contiene le informazioni di gestione. Nel caso di risposte che segnalano eccezioni, il valore di ciascun binding di variabile nell'elenco conterrà uno dei valori di eccezione: noSuchObject, noSuchInstance o endOfMibView.

Ogni binding di variabile è un accoppiamento di un nome e un valore. Il nome è un OBJECT IDENTIFIER che specifica una particolare istanza di oggetto e il valore rappresenta il valore dell'istanza di oggetto.

4.2. Elaborazione dei PDU

Questa sezione descrive l'elaborazione di ciascun tipo di PDU.

4.2.1. Il GetRequest-PDU

Il GetRequest-PDU viene generato da un'applicazione di generatore di comandi per recuperare il valore di istanze di oggetto specifiche.

Alla ricezione di un GetRequest-PDU, l'entità SNMP ricevente che supporta applicazioni di risponditore di comandi elabora ciascun binding di variabile nell'elenco di binding di variabili per produrre un Response-PDU. Tutti i campi del Response-PDU hanno gli stessi valori dei campi corrispondenti della richiesta ricevuta, salvo quanto indicato di seguito.

Ogni binding di variabile viene elaborato come segue:

1. Se il nome del binding di variabile corrisponde esattamente al nome di una variabile accessibile da questa richiesta, allora il campo valore del binding di variabile viene impostato sul valore della variabile denominata.

2. Altrimenti, se il nome del binding di variabile non ha un prefisso OBJECT IDENTIFIER che corrisponde esattamente al prefisso OBJECT IDENTIFIER di qualsiasi variabile accessibile da questa richiesta, allora il campo valore del binding di variabile viene impostato su noSuchObject.

3. Altrimenti, il campo valore del binding di variabile viene impostato su noSuchInstance.

Se l'elaborazione di un binding di variabile fallisce per una ragione diversa da quelle elencate sopra, allora il Response-PDU viene modificato per indicare una condizione di errore. Il campo error-status viene impostato su un valore che indica la natura dell'errore. Il valore del campo error-index viene impostato sull'indice del binding di variabile per il quale l'elaborazione è fallita (i binding di variabili sono numerati a partire da uno). Il campo variable-bindings viene quindi modificato: tutti i binding di variabili diversi da quello che ha causato l'errore vengono rimossi e il binding di variabile che ha causato l'errore viene sostituito con un binding di variabile identico, tranne per il fatto che il campo valore viene impostato su NULL.

Il Response-PDU generato viene restituito all'originatore del GetRequest-PDU.

4.2.2. Il GetNextRequest-PDU

Il GetNextRequest-PDU viene generato da un'applicazione di generatore di comandi per recuperare il valore di istanze di oggetto, dove il nome delle istanze di oggetto da recuperare è sconosciuto.

Alla ricezione di un GetNextRequest-PDU, l'entità SNMP ricevente che supporta applicazioni di risponditore di comandi elabora ciascun binding di variabile nell'elenco di binding di variabili per produrre un Response-PDU. Tutti i campi del Response-PDU hanno gli stessi valori dei campi corrispondenti della richiesta ricevuta, salvo quanto indicato di seguito.

Ogni binding di variabile viene elaborato come segue:

1. Il nome del binding di variabile viene posizionato nell'elenco ordinato lessicograficamente dei nomi di tutte le variabili che sono accessibili da questa richiesta (l'elenco ordinato è l'unione concettuale degli elenchi ordinati individuali di variabili mantenuti per tutte le viste MIB).

2. Viene determinato il nome del successore lessicografico più vicino al nome del binding di variabile. Questo è il nome della variabile lessicograficamente successiva che è accessibile da questa richiesta.

3. Se non esiste un successore lessicografico, il campo valore del binding di variabile viene impostato su endOfMibView e il campo nome del binding di variabile viene impostato sul nome dalla richiesta.

4. Altrimenti, il campo valore del binding di variabile viene impostato sul valore della variabile denominata e il campo nome del binding di variabile viene impostato sul nome di quella variabile.

Se l'elaborazione di un binding di variabile fallisce per una ragione diversa da quelle elencate sopra, allora il Response-PDU viene modificato per indicare una condizione di errore. Il campo error-status viene impostato su un valore che indica la natura dell'errore. Il valore del campo error-index viene impostato sull'indice del binding di variabile per il quale l'elaborazione è fallita. Il campo variable-bindings viene quindi modificato come descritto per l'elaborazione GetRequest-PDU.

Il Response-PDU generato viene restituito all'originatore del GetNextRequest-PDU.

4.2.2.1. Esempio di attraversamento di tabella

Uno degli usi più importanti del GetNextRequest-PDU è l'attraversamento di tabelle concettuali di informazioni all'interno di una MIB. La semantica di questo tipo di PDU rende tali attraversamenti abbastanza semplici.

Il primo GetNextRequest-PDU in un attraversamento viene emesso per ottenere la prima riga della tabella. I binding di variabili in questa richiesta nominano tipicamente gli oggetti di voce di tabella, ma possono anche nominare qualsiasi nome di oggetto precedente. La semantica del GetNextRequest-PDU detta che i binding di variabili restituiti saranno quelli della prima riga della tabella.

I GetNextRequest-PDU successivi vengono emessi per ottenere le righe successive della tabella. Ciascuno di questi PDU specifica nei suoi binding di variabili il nome della variabile restituita nel Response-PDU precedente. Poiché questi nomi sono ordinati lessicograficamente e poiché la semantica del GetNextRequest-PDU detta che i nomi restituiti sono i successori lessicografici di quelli nella richiesta, le righe della tabella vengono restituite in ordine lessicografico.

Il processo di attraversamento è completo quando il nome di una variabile restituita in un Response-PDU non ha il nome dell'oggetto di voce di tabella come prefisso. Ciò si verifica perché l'agente non ha più istanze in quella tabella o perché l'istanza di oggetto lessicograficamente successiva è un'istanza di un tipo di oggetto diverso (perché il tipo di oggetto lessicograficamente successivo non è un oggetto colonna di quella tabella o è un oggetto colonna di una tabella diversa).

Questo esempio dimostra l'attraversamento di tabella utilizzando il GetNextRequest-PDU. Utilizza la tabella fittizia "fooTable", che contiene tre oggetti:

fooIndex    OBJECT-TYPE
    SYNTAX      INTEGER
    MAX-ACCESS  not-accessible
    STATUS      current
    ::= { fooEntry 1 }

fooDescr    OBJECT-TYPE
    SYNTAX      DisplayString
    MAX-ACCESS  read-only
    STATUS      current
    ::= { fooEntry 2 }

fooValue    OBJECT-TYPE
    SYNTAX      INTEGER
    MAX-ACCESS  read-write
    STATUS      current
    ::= { fooEntry 3 }

Supponiamo che esistano le seguenti istanze:

fooIndex.1 = 1
fooDescr.1 = "alpha"
fooValue.1 = 10
fooIndex.2 = 2
fooDescr.2 = "beta"
fooValue.2 = 20

L'applicazione di generatore di comandi emette un GetNextRequest-PDU con i seguenti binding di variabili:

fooIndex
fooDescr
fooValue

L'agente risponde con un Response-PDU contenente:

fooIndex.1 = 1
fooDescr.1 = "alpha"
fooValue.1 = 10

L'applicazione di generatore di comandi emette un altro GetNextRequest-PDU con:

fooIndex.1
fooDescr.1
fooValue.1

L'agente risponde con:

fooIndex.2 = 2
fooDescr.2 = "beta"
fooValue.2 = 20

L'applicazione di generatore di comandi emette un altro GetNextRequest-PDU con:

fooIndex.2
fooDescr.2
fooValue.2

Se non ci sono più righe nella tabella, l'agente potrebbe rispondere con binding di variabili per oggetti che non sono in fooTable, indicando che è stata raggiunta la fine della tabella.

4.2.3. Il GetBulkRequest-PDU

Il GetBulkRequest-PDU viene generato da un'applicazione di generatore di comandi per recuperare in modo efficiente grandi quantità di dati, come più righe in una tabella.

Alla ricezione di un GetBulkRequest-PDU, l'entità SNMP ricevente che supporta applicazioni di risponditore di comandi elabora la richiesta come segue:

Il campo non-repeaters specifica il numero di binding di variabili nell'elenco di binding di variabili per i quali deve essere restituito un singolo successore lessicografico.

Il campo max-repetitions specifica il numero massimo di successori lessicografici da restituire per i binding di variabili rimanenti (quelli dopo i primi binding non-repeaters) nell'elenco di binding di variabili.

L'entità SNMP ricevente produce un Response-PDU secondo le seguenti regole:

1. Il campo request-id del Response-PDU viene impostato sul valore del campo request-id del GetBulkRequest-PDU ricevuto.

2. Il campo error-status del Response-PDU viene impostato su noError e il campo error-index viene impostato su zero.

3. L'elenco di binding di variabili del Response-PDU viene riempito secondo la seguente procedura:

   a. Sia N il numero di binding di variabili nell'elenco di binding di variabili del GetBulkRequest-PDU.

   b. Sia M il valore del campo max-repetitions del GetBulkRequest-PDU.

   c. Sia R il valore del campo non-repeaters del GetBulkRequest-PDU.

   d. Per i primi R binding di variabili nell'elenco di binding di variabili del GetBulkRequest-PDU, eseguire l'operazione GetNext per ciascuno e posizionare i risultati nell'elenco di binding di variabili del Response-PDU.

   e. Per ciascuno dei (N - R) binding di variabili rimanenti nell'elenco di binding di variabili del GetBulkRequest-PDU, i seguenti passaggi vengono eseguiti M volte, o fino a quando non ci sono più successori lessicografici:

   i. Eseguire l'operazione GetNext per il binding di variabile.

   ii. Posizionare il risultato nell'elenco di binding di variabili del Response-PDU.

   iii. Utilizzare il risultato come base per l'iterazione successiva (se presente) di questo passaggio.

4. Se la dimensione del Response-PDU generato supera una limitazione locale o la dimensione massima del messaggio della parte di origine della richiesta, allora la risposta viene generata con un elenco di binding di variabili alternativo, utilizzando un valore inferiore per max-repetitions o meno binding di variabili, in modo che i vincoli di dimensione siano soddisfatti. Si noti che in questo caso, se viene utilizzato un valore inferiore per max-repetitions, il valore del campo max-repetitions nel Response-PDU sarà comunque impostato sul valore dal GetBulkRequest-PDU (cioè, non viene decrementato per riflettere il valore inferiore effettivamente utilizzato).

Se l'elaborazione di un binding di variabile fallisce per una ragione diversa da quelle elencate sopra, allora il Response-PDU viene modificato per indicare una condizione di errore. Il campo error-status viene impostato su un valore che indica la natura dell'errore. Il valore del campo error-index viene impostato sull'indice del binding di variabile nel GetBulkRequest-PDU per il quale l'elaborazione è fallita. Il campo variable-bindings viene quindi modificato come descritto per l'elaborazione GetRequest-PDU.

Il Response-PDU generato viene restituito all'originatore del GetBulkRequest-PDU.

4.2.3.1. Un altro esempio di attraversamento di tabella

Questo esempio dimostra l'uso del GetBulkRequest-PDU per recuperare più righe da una tabella. Consideriamo la stessa "fooTable" dell'esempio precedente.

L'applicazione di generatore di comandi desidera recuperare fino a due righe da fooTable. Emette un GetBulkRequest-PDU con:

• non-repeaters = 0
• max-repetitions = 2
• binding di variabili:

  fooIndex
  fooDescr
  fooValue

L'agente risponde con un Response-PDU contenente fino a 2 × 3 = 6 binding di variabili:

fooIndex.1 = 1
fooDescr.1 = "alpha"
fooValue.1 = 10
fooIndex.2 = 2
fooDescr.2 = "beta"
fooValue.2 = 20

Se ci fossero più righe nella tabella, l'applicazione di generatore di comandi potrebbe continuare emettendo un altro GetBulkRequest-PDU utilizzando gli ultimi nomi di oggetto restituiti come punto di partenza.

Il vantaggio del GetBulkRequest-PDU è che riduce il numero di scambi di protocollo richiesti per recuperare una grande tabella, consentendo di recuperare più righe in una singola operazione.

4.2.4. Il Response-PDU

Il Response-PDU viene generato da un'entità SNMP che supporta applicazioni di risponditore di comandi in risposta a GetRequest-PDU, GetNextRequest-PDU, GetBulkRequest-PDU, SetRequest-PDU o InformRequest-PDU, come indicato dalle procedure specificate nelle sezioni 4.2.1, 4.2.2, 4.2.3, 4.2.5 e 4.2.7, rispettivamente.

Alla ricezione di un Response-PDU, l'entità SNMP ricevente che supporta applicazioni di generatore di comandi o ricevitore di notifiche lo elabora secondo le procedure dell'applicazione.

Il campo request-id del Response-PDU viene utilizzato dall'entità ricevente per correlare la risposta con la richiesta originale.

Il campo error-status del Response-PDU può essere impostato su uno dei seguenti valori:

• noError: Indica che non si sono verificati errori durante l'elaborazione della richiesta.

• tooBig: Indica che l'agente non è riuscito a generare un Response-PDU la cui dimensione rientrasse nei vincoli locali o nella dimensione massima del messaggio dell'origine della richiesta.

• noSuchName: Utilizzato per la compatibilità proxy. Questo errore non dovrebbe essere generato da un'entità SNMPv2.

• badValue: Utilizzato per la compatibilità proxy. Questo errore non dovrebbe essere generato da un'entità SNMPv2.

• readOnly: Utilizzato per la compatibilità proxy. Questo errore non dovrebbe essere generato da un'entità SNMPv2.

• genErr: Indica che si è verificato un errore diverso da uno dei precedenti durante l'elaborazione.

• noAccess: Indica che l'accesso all'oggetto è stato negato per motivi di sicurezza.

• wrongType: Indica che il campo valore del binding di variabile ha il tipo errato per l'oggetto specificato.

• wrongLength: Indica che il campo valore del binding di variabile ha la lunghezza errata per l'oggetto specificato.

• wrongEncoding: Indica che il campo valore del binding di variabile ha la codifica errata per l'oggetto specificato.

• wrongValue: Indica che il campo valore del binding di variabile ha un valore che non è un valore valido per l'oggetto specificato.

• noCreation: Indica che l'istanza di oggetto specificata non può essere creata.

• inconsistentValue: Indica che il campo valore del binding di variabile è incoerente con i valori di altri oggetti.

• resourceUnavailable: Indica che le risorse necessarie non sono disponibili per eseguire l'operazione richiesta.

• commitFailed: Indica che il tentativo di confermare i valori è fallito.

• undoFailed: Indica che il tentativo di annullare il set precedente di valori è fallito.

• authorizationError: Indica che l'accesso all'oggetto specificato non è autorizzato.

• notWritable: Indica che l'oggetto specificato non è scrivibile.

• inconsistentName: Indica che il nome dell'istanza di oggetto specificato è incoerente con i valori di altri oggetti.

Il campo error-index viene impostato su zero in un Response-PDU generato in risposta a un GetRequest-PDU, GetNextRequest-PDU o GetBulkRequest-PDU che non ha determinato un errore. Altrimenti, viene impostato sull'indice del binding di variabile che ha causato l'errore.

4.2.5. Il SetRequest-PDU

Il SetRequest-PDU viene generato da un'applicazione di generatore di comandi per richiedere che i valori di una o più istanze di oggetto vengano modificati.

Alla ricezione di un SetRequest-PDU, l'entità SNMP ricevente che supporta applicazioni di risponditore di comandi tenta di impostare i valori delle istanze di oggetto denominate nell'elenco di binding di variabili ai valori specificati.

L'elaborazione del SetRequest-PDU viene eseguita in due fasi:

Fase uno:

Nella prima fase, la richiesta viene convalidata. Se tutte le convalide hanno successo, allora viene avviata la seconda fase. Se una convalida fallisce, allora l'intera operazione fallisce e viene generato un Response-PDU con il campo error-status impostato per indicare la natura dell'errore e il campo error-index impostato sull'indice del binding di variabile che ha causato l'errore.

Le seguenti convalide vengono eseguite nella prima fase:

1. L'oggetto denominato da ciascun binding di variabile viene convalidato per garantire che:

   • Il nome sia un OBJECT IDENTIFIER valido
   • L'oggetto esista e sia accessibile
   • L'oggetto sia scrivibile

2. Il valore di ciascun binding di variabile viene convalidato per garantire che:

   • La sintassi sia corretta
   • La lunghezza sia appropriata
   • Il valore sia nell'intervallo accettabile
   • Il valore sia coerente con i valori degli oggetti correlati

Fase due:

Se la prima fase si completa con successo, inizia la seconda fase. In questa fase, i valori delle istanze di oggetto vengono impostati.

Se la seconda fase fallisce per qualsiasi motivo, viene effettuato un tentativo di annullare tutte le modifiche apportate durante questa fase (un "rollback"). Se il rollback ha successo, viene generato un Response-PDU con error-status impostato su commitFailed. Se il rollback fallisce, viene generato un Response-PDU con error-status impostato su undoFailed.

Se la seconda fase si completa con successo, viene generato un Response-PDU con:

• error-status impostato su noError
• error-index impostato su zero
• elenco variable-bindings contenente i nomi e i valori di tutte le istanze di oggetto che sono state impostate con successo

Il Response-PDU generato viene restituito all'originatore del SetRequest-PDU.

Atomicità:

Il SetRequest-PDU è atomico - o tutte le variabili vengono aggiornate o nessuna lo è. Ciò garantisce che il sistema gestito non venga mai lasciato in uno stato intermedio incoerente.

4.2.6. Il SNMPv2-Trap-PDU

Il SNMPv2-Trap-PDU viene generato da un'entità SNMP che supporta applicazioni di originatore di notifiche per conto di un'applicazione di generatore di notifiche. Viene utilizzato per fornire notifiche non richieste di eventi a un'entità SNMP che supporta applicazioni di ricevitore di notifiche.

I primi due binding di variabili nell'elenco di binding di variabili di un SNMPv2-Trap-PDU sono rispettivamente sysUpTime.0 [RFC3418] e snmpTrapOID.0 [RFC3418]. Il binding di variabile sysUpTime.0 rappresenta il tempo trascorso tra l'ultima inizializzazione dell'entità SNMP e la generazione del trap. Il binding di variabile snmpTrapOID.0 identifica il tipo di trap che viene inviato.

Se l'invocazione della macro NOTIFICATION-TYPE corrispondente al valore di snmpTrapOID.0 include clausole OBJECTS, allora l'elenco di binding di variabili include anche binding di variabili per gli oggetti specificati in quelle clausole. Ulteriori binding di variabili possono essere inclusi nell'elenco di binding di variabili a discrezione dell'applicazione di originatore di notifiche.

Alla ricezione di un SNMPv2-Trap-PDU, l'entità SNMP ricevente che supporta applicazioni di ricevitore di notifiche elabora il trap secondo le procedure dell'applicazione ricevente. Non viene generata alcuna risposta a un SNMPv2-Trap-PDU.

4.2.7. Il InformRequest-PDU

Il InformRequest-PDU viene generato da un'entità SNMP che supporta applicazioni di originatore di notifiche per conto di un'applicazione di generatore di notifiche. Viene utilizzato per fornire notifiche di eventi a un'entità SNMP che supporta applicazioni di ricevitore di notifiche, con conferma di ricezione.

I primi due binding di variabili nell'elenco di binding di variabili di un InformRequest-PDU sono rispettivamente sysUpTime.0 e snmpTrapOID.0, come descritto per SNMPv2-Trap-PDU.

Alla ricezione di un InformRequest-PDU, l'entità SNMP ricevente che supporta applicazioni di ricevitore di notifiche elabora l'inform secondo le procedure dell'applicazione ricevente e genera un Response-PDU. Il Response-PDU ha lo stesso valore nel suo campo request-id dell'InformRequest-PDU ricevuto, un error-status di noError e un error-index di zero. Il campo variable-bindings del Response-PDU è identico a quello dell'InformRequest-PDU ricevuto.

Il Response-PDU generato viene restituito all'originatore dell'InformRequest-PDU. Ciò fornisce una conferma che la notifica è stata ricevuta.