Passa al contenuto principale

RFC 1157 - Protocollo semplice di gestione di rete (SNMP)

Gruppo di lavoro di rete Request for Comments: 1157 Obsoleta: RFC 1098

Autori: J. Case (SNMP Research) M. Fedor (Performance Systems International) M. Schoffstall (Performance Systems International) J. Davin (MIT Laboratory for Computer Science)

Data: May 1990

Indice​

1. Stato di questo documento​

Questa RFC è una riedizione della RFC 1098, con una sezione modificata "Stato di questo promemoria" più alcune piccole correzioni tipografiche. Questo memo definisce un semplice protocollo mediante il quale le informazioni di gestione per un elemento di rete possono essere controllate o modificate da utenti logicamente remoti. In particolare, insieme ai promemoria associati che descrivono la struttura delle informazioni di gestione insieme alla base delle informazioni di gestione, questi documenti forniscono un'architettura e un sistema semplici e funzionanti per la gestione delle Internet basate su TCP/IP e in particolare di Internet.

L'Internet Activity Board raccomanda che tutte le implementazioni IP e TCP siano gestibili in rete. Ciò implica l'implementazione di Internet MIB (RFC-1156) e di almeno uno dei due protocolli di gestione consigliati SNMP (RFC-1157) o CMOT (RFC-1095). Va notato che, al momento, SNMP è uno standard Internet completo e CMOT è una bozza di standard. Consultare anche le RFC sui requisiti host e gateway per informazioni più specifiche sull'applicabilità di questo standard.

Fare riferimento all'ultima edizione della RFC "IAB Official Protocol Standards" per informazioni aggiornate sullo stato e sullo stato dei protocolli Internet standard.

La distribuzione di questo promemoria è illimitata.

2. Introduzione​

Come riportato nella RFC 1052, Raccomandazioni IAB per lo sviluppo di standard di gestione della rete Internet [1], è stata intrapresa una strategia su due fronti per la gestione della rete di Internet basati su TCP/IP. Per la gestione dei nodi della comunità Internet si sarebbe dovuto utilizzare a breve termine il Simple Network Management Protocol (SNMP). A lungo termine si sarebbe dovuto esaminare l'utilizzo del framework di gestione della rete OSI. Sono stati prodotti due documenti per definire le informazioni di gestione: RFC 1065, che definiva la struttura delle informazioni di gestione (SMI) [2], e RFC 1066, che definiva la base di informazioni di gestione (MIB) [3]. Entrambi questi documenti sono stati progettati in modo da essere compatibili sia con il framework di gestione della rete SNMP che OSI.

Questa strategia ha avuto un discreto successo nel breve termine: la tecnologia di gestione della rete basata su Internet è stata messa in campo, sia dalla comunità di ricerca che da quella commerciale, nel giro di pochi mesi. Di conseguenza, porzioni della comunità Internet sono diventate gestibili in rete in modo tempestivo.

Come riportato nella RFC 1109, Rapporto del secondo gruppo di revisione della gestione della rete ad hoc [4], i requisiti dei framework di gestione della rete SNMP e OSI erano più diversi del previsto. Pertanto, il requisito di compatibilità tra SMI/MIB ed entrambi i framework è stato sospeso. Questa azione ha consentito al framework di gestione operativa della rete, SNMP, di rispondere alle nuove esigenze operative della comunità Internet producendo documenti che definiscono nuovi elementi MIB.

Lo IAB ha designato SNMP, SMI e Internet MIB iniziale come "protocolli standard" completi con lo stato "consigliato". Con questa azione, lo IAB raccomanda che tutte le implementazioni IP e TCP siano gestibili in rete e che si prevede che le implementazioni gestibili in rete adottino e implementino SMI, MIB e SNMP.

Pertanto, l'attuale framework di gestione della rete per le Internet basate su TCP/IP è costituito da: Struttura e identificazione delle informazioni di gestione per le Internet basate su TCP/IP, che descrive come gli oggetti gestiti contenuti nell'MIB sono definiti come stabilito nella RFC 1155 [5]; Management Information Base per la gestione della rete di Internet basati su TCP/IP, che descrive gli oggetti gestiti contenuti in MIB come stabilito in RFC 1156 [6]; e, il Simple Network Management Protocol, che definisce il protocollo utilizzato per gestire questi oggetti, come indicato in questo memo.

Come riportato nella RFC 1052, Raccomandazioni IAB per lo sviluppo di standard di gestione della rete Internet [1], l'Internet Activity Board ha incaricato l'Internet Engineering Task Force (IETF) di creare due nuovi gruppi di lavoro nell'area della gestione della rete. Un gruppo è stato incaricato di specificare e definire ulteriormente gli elementi da includere nella Management Information Base (MIB). L'altro è stato incaricato di definire le modifiche al Simple Network Management Protocol (SNMP) per soddisfare le esigenze a breve termine del fornitore di rete e delle comunità operative e per allinearsi con i risultati del gruppo di lavoro MIB.

Il gruppo di lavoro MIB ha prodotto due promemoria, uno che definisce una struttura per le informazioni di gestione (SMI) [2] per l'utilizzo da parte degli oggetti gestiti contenuti in MIB. Una seconda nota [3] definisce l'elenco degli oggetti gestiti.

L'output del gruppo di lavoro sulle estensioni SNMP è questo memo, che incorpora le modifiche alla definizione iniziale di SNMP [7] necessarie per ottenere l'allineamento con l'output del gruppo di lavoro MIB. Le modifiche dovrebbero essere minime per essere coerenti con la direttiva dello IAB secondo cui i gruppi di lavoro devono essere "estremamente sensibili alla necessità di mantenere semplice l'SNMP". Sebbene sia stata prestata molta attenzione e dibattito alle modifiche apportate al SNMP che si riflettono in questo memo, il protocollo risultante non è retrocompatibile con il suo predecessore, il Simple Gateway Monitoring Protocol (SGMP) [8]. Sebbene la sintassi del protocollo sia stata modificata, la filosofia originale, le decisioni di progettazione e l'architettura rimangono intatte. Al fine di evitare confusione, le nuove porte UDP sono state assegnate per l'utilizzo da parte del protocollo descritto in questo memo.

3. L'architettura SNMP​

Nel modello architettonico SNMP è implicita una raccolta di stazioni di gestione della rete ed elementi di rete. Le stazioni di gestione della rete eseguono applicazioni di gestione che monitorano e controllano gli elementi della rete. Gli elementi di rete sono dispositivi come host, gateway, server terminali e simili, che hanno agenti di gestione responsabili di eseguire le funzioni di gestione della rete richieste dalle stazioni di gestione della rete. Il Simple Network Management Protocol (SNMP) viene utilizzato per comunicare le informazioni di gestione tra le stazioni di gestione della rete e gli agenti negli elementi di rete.

3.1. Obiettivi dell'architettura​

SNMP riduce esplicitamente al minimo il numero e la complessità delle funzioni di gestione realizzate dall'agente di gestione stesso. Questo obiettivo è interessante sotto almeno quattro aspetti:

  1. Il costo di sviluppo del software dell'agente di gestione necessario per supportare il protocollo viene conseguentemente ridotto.

  2. Il grado di funzione di gestione supportata da remoto viene conseguentemente aumentato, consentendo così il massimo utilizzo delle risorse Internet nell'attività di gestione.

  3. Il livello delle funzioni di gestione supportate da remoto viene conseguentemente aumentato, imponendo così il minor numero possibile di restrizioni sulla forma e sulla sofisticazione degli strumenti di gestione.

  4. Gli insiemi semplificati di funzioni di gestione sono facilmente comprensibili e utilizzati dagli sviluppatori di strumenti di gestione della rete.

Un secondo obiettivo del protocollo è che il paradigma funzionale per il monitoraggio e il controllo sia sufficientemente estensibile per accogliere aspetti aggiuntivi, possibilmente imprevisti, del funzionamento e della gestione della rete.

Un terzo obiettivo è che l'architettura sia, per quanto possibile, indipendente dall'architettura e dai meccanismi di particolari host o particolari gateway.

3.2. Elementi dell'architettura​

L’architettura SNMP articola una soluzione al problema della gestione della rete in termini di:

  1. la portata delle informazioni gestionali comunicate dal protocollo,

  2. la rappresentazione delle informazioni gestionali comunicate dal protocollo,

  3. operazioni sulle informazioni gestionali supportate dal protocollo,

  4. la forma e il significato degli scambi tra gli enti di gestione,

  5. la definizione dei rapporti amministrativi tra gli enti di gestione, e

  6. la forma e il significato dei riferimenti alle informazioni sulla gestione.

3.2.1. Ambito delle informazioni di gestione​

L'ambito delle informazioni di gestione comunicate dal funzionamento dell'SNMP è esattamente quello rappresentato da istanze di tutti i tipi di oggetti non aggregati definiti nello standard Internet MIB o definiti altrove secondo le convenzioni stabilite nello standard Internet SMI [5].

Il supporto per i tipi di oggetti aggregati in MIB non è richiesto per la conformità con SMI né realizzato da SNMP.

3.2.2. Rappresentazione delle informazioni di gestione​

Le informazioni di gestione comunicate dal funzionamento dell'SNMP sono rappresentate secondo il sottoinsieme del linguaggio ASN.1 [9] specificato per la definizione dei tipi non aggregati nell'SMI.

L'SGMP ha adottato la convenzione di utilizzare un sottoinsieme ben definito del linguaggio ASN.1 [9]. SNMP continua ed estende questa tradizione utilizzando un sottoinsieme moderatamente più complesso di ASN.1 per descrivere gli oggetti gestiti e per descrivere le unità di dati del protocollo utilizzate per la gestione di tali oggetti. Inoltre, il desiderio di facilitare l'eventuale transizione ai protocolli di gestione di rete basati su OSI ha portato alla definizione nel linguaggio ASN.1 di una struttura standard Internet di informazioni di gestione (SMI) [5] e di una base di informazioni di gestione (MIB) [6]. L'uso del linguaggio ASN.1 è stato, in parte, incoraggiato dall'uso riuscito di ASN.1 nei primi sforzi, in particolare SGMP. Le restrizioni sull'uso di ASN.1 che fanno parte di SMI contribuiscono alla semplicità sposata e convalidata dall'esperienza con SGMP. Sempre per semplicità, SNMP utilizza solo un sottoinsieme delle regole di codifica di base di ASN.1 [10]. Vale a dire, tutte le codifiche utilizzano la forma a lunghezza definita. Inoltre, quando consentito, vengono utilizzate codifiche non-costruttore anziché codifiche costruttore. Questa restrizione si applica a tutti gli aspetti della codifica ASN.1, sia per le unità dati del protocollo di livello superiore che per gli oggetti dati in esse contenuti.

3.2.3. Operazioni supportate sulle informazioni di gestione​

SNMP modella tutte le funzioni dell'agente di gestione come alterazioni o ispezioni di variabili. Pertanto, un'entità di protocollo su un host logicamente remoto (possibilmente l'elemento di rete stesso) interagisce con l'agente di gestione residente sull'elemento di rete per recuperare (ottenere) o alterare (impostare) variabili. Questa strategia ha almeno due conseguenze positive:

  1. Ha l'effetto di limitare a due il numero di funzioni di gestione essenziali realizzate dall'agente di gestione: un'operazione per assegnare un valore a una configurazione specifica o ad un altro parametro e un'altra per recuperare tale valore.

  2. Un secondo effetto di questa decisione è quello di evitare di introdurre nella definizione del protocollo il supporto per comandi di gestione imperativi: il numero di tali comandi è in pratica sempre in aumento, e la semantica di tali comandi è in generale arbitrariamente complessa.

La strategia implicita nell'SNMP è che il monitoraggio dello stato della rete a qualsiasi livello significativo di dettaglio viene effettuato principalmente richiedendo informazioni appropriate da parte dei centri di monitoraggio. Un numero limitato di messaggi non richiesti (trappole) guida la tempistica e il focus del sondaggio. Limitare il numero di messaggi non richiesti è coerente con l'obiettivo di semplicità e di minimizzazione della quantità di traffico generato dalla funzione di gestione della rete.

È improbabile che l'esclusione dei comandi imperativi dall'insieme delle funzioni di gestione esplicitamente supportate precluda qualsiasi operazione auspicabile dell'agente di gestione. Attualmente, la maggior parte dei comandi sono richiesti per impostare il valore di alcuni parametri o per recuperare tale valore, e la funzione dei pochi comandi imperativi attualmente supportati è facilmente gestita in modalità asincrona da questo modello di gestione. In questo schema, un comando imperativo potrebbe essere realizzato come l'impostazione di un valore di parametro che successivamente attiva l'azione desiderata. Ad esempio, anziché implementare un "comando di riavvio", questa azione potrebbe essere invocata semplicemente impostando un parametro che indica il numero di secondi rimanenti fino al riavvio del sistema.

3.2.4. Forma e significato degli scambi di protocollo​

La comunicazione delle informazioni di gestione tra le entità di gestione viene realizzata nell'SNMP attraverso lo scambio di messaggi di protocollo. La forma e il significato di tali messaggi sono definiti di seguito nella Sezione 4.

Coerentemente con l'obiettivo di ridurre al minimo la complessità dell'agente di gestione, lo scambio di messaggi SNMP richiede solo un servizio di datagramma inaffidabile e ogni messaggio è interamente e indipendentemente rappresentato da un singolo datagramma di trasporto. Mentre questo documento specifica lo scambio di messaggi tramite il protocollo UDP [11], i meccanismi dell'SNMP sono generalmente adatti per l'uso con un'ampia varietà di servizi di trasporto.

3.2.5. Definizione delle relazioni amministrative​

L'architettura SNMP ammette una varietà di relazioni amministrative tra le entità che partecipano al protocollo. Le entità che risiedono nelle stazioni di gestione e negli elementi di rete che comunicano tra loro utilizzando SNMP sono denominate entità applicative SNMP. I processi peer che implementano SNMP, e quindi supportano le entità applicative SNMP, sono definiti entità di protocollo.

Un abbinamento di un agente SNMP con un insieme arbitrario di entità applicative SNMP è chiamato comunità SNMP. Ciascuna comunità SNMP prende il nome da una stringa di ottetti, che viene chiamata il nome della comunità per detta comunità.

Un messaggio SNMP originato da un'entità applicativa SNMP che di fatto appartiene alla comunità SNMP denominata dal componente comunità di detto messaggio è chiamato messaggio SNMP autentico. L'insieme di regole in base alle quali un messaggio SNMP viene identificato come messaggio SNMP autentico per una particolare comunità SNMP è chiamato schema di autenticazione. Un'implementazione di una funzione che identifica i messaggi SNMP autentici secondo uno o più schemi di autenticazione è chiamata servizio di autenticazione.

Chiaramente, una gestione efficace delle relazioni amministrative tra le entità applicative SNMP richiede servizi di autenticazione che (mediante l'uso di crittografia o altre tecniche) siano in grado di identificare i messaggi SNMP autentici con un elevato grado di certezza. Alcune implementazioni SNMP potrebbero voler supportare solo un banale servizio di autenticazione che identifica tutti i messaggi SNMP come messaggi SNMP autentici.

Per qualsiasi elemento di rete, un sottoinsieme di oggetti nell'MIB che appartengono a quell'elemento è chiamato vista SNMP MIB. Si noti che i nomi dei tipi di oggetto rappresentati in una vista SNMP MIB non devono necessariamente appartenere a un singolo sottoalbero dello spazio dei nomi del tipo di oggetto.

Un elemento dell'insieme { READ-ONLY, READ-WRITE } è chiamato modalità di accesso SNMP.

L'abbinamento di una modalità di accesso SNMP con una vista SNMP MIB è denominato profilo comunità SNMP. Un profilo comunità SNMP rappresenta i privilegi di accesso specificati alle variabili in una vista MIB specificata. Per ogni variabile nella vista MIB in un dato profilo comunità SNMP, l'accesso a tale variabile è rappresentato dal profilo secondo le seguenti convenzioni:

  1. se detta variabile è definita nell'MIB con "Accesso:" uguale a "nessuno", non è disponibile come operando per nessun operatore;

  2. se detta variabile è definita in MIB con "Accesso:" di "lettura-scrittura" o "sola scrittura" e la modalità di accesso del profilo specificato è READ-WRITE, quella variabile è disponibile come operando per le operazioni get, set e trap;

  3. in caso contrario, la variabile è disponibile come operando per le operazioni get e trap.

  4. Nei casi in cui una variabile di "sola scrittura" è un operando utilizzato per le operazioni get o trap, il valore fornito per la variabile è specifico dell'implementazione.

L'associazione di una comunità SNMP con un profilo comunità SNMP è denominata politica di accesso SNMP. Una politica di accesso rappresenta un profilo di comunità specifico offerto dall'agente SNMP di una comunità SNMP specificata ad altri membri di quella comunità. Tutte le relazioni amministrative tra le entità dell'applicazione SNMP sono definite a livello architettonico in termini di politiche di accesso SNMP.

Per ogni policy di accesso SNMP, se l'elemento di rete su cui risiede l'agente SNMP per la comunità SNMP specificata non è quello a cui appartiene la vista MIB per il profilo specificato, tale policy viene denominata policy di accesso proxy SNMP. L'agente SNMP associato a una policy di accesso proxy è denominato agente proxy SNMP. Sebbene una definizione imprudente delle politiche di accesso ai proxy possa dar luogo a cicli di gestione, una definizione prudente delle politiche dei proxy è utile in almeno due modi:

  1. Permette il monitoraggio e il controllo di elementi di rete altrimenti non indirizzabili tramite il protocollo di gestione e il protocollo di trasporto. Cioè, un agente proxy può fornire una funzione di conversione di protocollo che consente a una stazione di gestione di applicare una struttura di gestione coerente a tutti gli elementi della rete, inclusi dispositivi come modem, multiplexor e altri dispositivi che supportano diverse strutture di gestione.

  2. Potenzialmente protegge gli elementi della rete da elaborate politiche di controllo degli accessi. Ad esempio, un agente proxy può implementare un sofisticato controllo degli accessi per cui diversi sottoinsiemi di variabili all'interno dell'MIB sono resi accessibili a diverse stazioni di gestione senza aumentare la complessità dell'elemento di rete.

A titolo di esempio, la Figura 1 illustra la relazione tra stazioni di gestione, agenti proxy e agenti di gestione. In questo esempio, si prevede che l'agente proxy sia un normale centro operativo di rete Internet (INOC) di un dominio amministrativo che ha una relazione gestionale standard con un insieme di agenti di gestione.

   +------------------+       +----------------+      +----------------+
   |  Region #1 INOC  |       |Region #2 INOC  |      |PC in Region #3 |
   |                  |       |                |      |                |
   |Domain=Region #1  |       |Domain=Region #2|      |Domain=Region #3|
   |CPU=super-mini-1  |       |CPU=super-mini-1|      |CPU=Clone-1     |
   |PCommunity=pub    |       |PCommunity=pub  |      |PCommunity=slate|
   |                  |       |                |      |                |
   +------------------+       +----------------+      +----------------+
          /|\                      /|\                     /|\
           |                        |                       |
           |                        |                       |
           |                       \|/                      |
           |               +-----------------+              |
           +-------------->| Region #3 INOC  |<-------------+
                           |                 |
                           |Domain=Region #3 |
                           |CPU=super-mini-2 |
                           |PCommunity=pub,  |
                           |         slate   |
                           |DCommunity=secret|
           +-------------->|                 |<-------------+
           |               +-----------------+              |
           |                       /|\                      |
           |                        |                       |
           |                        |                       |
          \|/                      \|/                     \|/
   +-----------------+     +-----------------+       +-----------------+
   |Domain=Region#3  |     |Domain=Region#3  |       |Domain=Region#3  |
   |CPU=router-1     |     |CPU=mainframe-1  |       |CPU=modem-1      |
   |DCommunity=secret|     |DCommunity=secret|       |DCommunity=secret|
   +-----------------+     +-----------------+       +-----------------+

Dominio: il dominio amministrativo dell'elemento PCommunity: il nome di una comunità che utilizza un proxy agent DCommunity: il nome di una comunità diretta

Figura 1 Esempio di configurazione di gestione della rete

3.2.6. Forma e significato dei riferimenti agli oggetti gestiti​

L'SMI richiede che la definizione di un protocollo di gestione conforme indirizzi:

  1. la risoluzione di riferimenti MIB ambigui,

  2. la risoluzione dei riferimenti MIB in presenza di più versioni MIB e

  3. l'identificazione di istanze particolari dei tipi di oggetto definiti nel MIB.

3.2.6.1. Risoluzione dei riferimenti MIB ambigui​

Poiché l'ambito di qualsiasi operazione SNMP è concettualmente limitato a oggetti rilevanti per un singolo elemento di rete e poiché tutti i riferimenti SNMP a oggetti MIB sono (implicitamente o esplicitamente) tramite nomi di variabili univoci, non vi è alcuna possibilità che qualsiasi riferimento SNMP a qualsiasi tipo di oggetto definito in MIB possa risolversi in più istanze di quel tipo.

3.2.6.2. Risoluzione dei riferimenti tra versioni della MIB​

L'istanza dell'oggetto a cui fa riferimento qualsiasi operazione SNMP è esattamente quella specificata come parte della richiesta dell'operazione o (nel caso di un'operazione get-next) il suo immediato successore nell'MIB nel suo insieme. In particolare, un riferimento ad un oggetto come parte di una qualche versione dello standard Internet MIB non si risolve ad alcun oggetto che non sia parte di detta versione dello standard Internet MIB, tranne nel caso in cui l'operazione richiesta sia get-next e il nome dell'oggetto specificato sia lessicograficamente ultimo tra i nomi di tutti gli oggetti presentati come parte di detta versione dello standard Internet MIB.

3.2.6.3. Identificazione delle istanze di oggetto​

I nomi per tutti i tipi di oggetto nell'MIB sono definiti esplicitamente nello standard Internet MIB o in altri documenti conformi alle convenzioni di denominazione dell'SMI. SMI richiede che i protocolli di gestione conformi definiscano meccanismi per identificare singole istanze di quei tipi di oggetto per un particolare elemento di rete.

Ciascuna istanza di qualsiasi tipo di oggetto definito in MIB viene identificata nelle operazioni SNMP da un nome univoco chiamato "nome variabile". In generale, il nome di una variabile SNMP è un OBJECT IDENTIFIER della forma x.y, dove x è il nome di un tipo di oggetto non aggregato definito in MIB e y è un frammento OBJECT IDENTIFIER che, in un modo specifico per il tipo di oggetto denominato, identifica l'istanza desiderata.

Questa strategia di denominazione consente il massimo sfruttamento della semantica dell'GetNextRequest-PDU (vedere Sezione 4), poiché assegna nomi alle variabili correlate in modo da essere contigui nell'ordinamento lessicografico di tutti i nomi delle variabili conosciute nell'MIB.

La denominazione specifica del tipo delle istanze di oggetto è definita di seguito per un numero di classi di tipi di oggetto. Le istanze di un tipo di oggetto a cui non è applicabile nessuna delle seguenti convenzioni di denominazione sono denominate da IDENTIFICATORI DI OGGETTO nella forma x.0, dove x è il nome di detto tipo di oggetto nella definizione MIB.

Ad esempio, supponiamo di voler identificare un'istanza della variabile sysDescr. La classe oggetto per sysDescr è:

             iso org dod internet mgmt mib system sysDescr
              1   3   6     1      2    1    1       1

Pertanto, il tipo di oggetto, x, sarebbe 1.3.6.1.2.1.1.1 a cui viene aggiunto un sottoidentificatore di istanza pari a 0. Cioè, 1.3.6.1.2.1.1.1.0 identifica la sola e unica istanza di sysDescr.

3.2.6.3.1. Nomi dei tipi di oggetto ifTable​

Il nome di un'interfaccia di sottorete, s, è il valore OBJECT IDENTIFIER del formato i, dove i ha il valore dell'istanza del tipo di oggetto ifIndex associato a s.

Per ogni tipo di oggetto, t, per il quale il nome definito, n, ha il prefisso ifEntry, un'istanza, i, di t è denominata da un OBJECT IDENTIFIER nella forma n.s, dove s è il nome dell'interfaccia di sottorete su cui i rappresenta le informazioni.

Ad esempio, si supponga di voler identificare l'istanza della variabile ifType associata all'interfaccia 2. Di conseguenza, ifType.2 identificherebbe l'istanza desiderata.

3.2.6.3.2. Nomi dei tipi di oggetto atTable​

Il nome di un indirizzo di rete memorizzato nella cache AT, x, è un OBJECT IDENTIFIER nel formato 1.a.b.c.d, dove a.b.c.d è il valore (nella familiare notazione "punto") del tipo di oggetto atNetAddress associato a x.

Il nome di un'equivalenza di traduzione di indirizzo e è un valore OBJECT IDENTIFIER nella forma s.w, tale che s è il valore di quell'istanza del tipo di oggetto atIndex associato a e e tale che w è il nome dell'indirizzo di rete memorizzato nella cache AT associato a e. Per ogni tipo di oggetto, t, per il quale il nome definito, n, ha il prefisso atEntry, un'istanza, i, di t è denominata da un OBJECT IDENTIFIER della forma n.y, dove y è il nome dell'equivalenza di traduzione dell'indirizzo su cui i rappresenta le informazioni.

Ad esempio, si supponga di voler trovare l'indirizzo fisico di una voce nella tabella di traduzione degli indirizzi (cache ARP) associata a un indirizzo IP di 89.1.1.42 e all'interfaccia 3. Di conseguenza, atPhysAddress.3.1.89.1.1.42 identificherebbe l'istanza desiderata.

3.2.6.3.3. Nomi dei tipi di oggetto ipAddrTable​

Il nome di un elemento di rete indirizzabile IP, x, è OBJECT IDENTIFIER nella forma a.b.c.d tale che a.b.c.d è il valore (nella familiare notazione "punto") di quell'istanza del tipo di oggetto ipAdEntAddr associato a x.

Per ciascun tipo di oggetto, t, per il quale il nome definito, n, ha il prefisso ipAddrEntry, un'istanza, i, di t è denominata da un OBJECT IDENTIFIER della forma n.y, dove y è il nome dell'elemento di rete indirizzabile IP su cui i rappresenta le informazioni.

Ad esempio, si supponga di voler trovare la maschera di rete di una voce nella tabella di interfaccia IP associata ad un indirizzo IP di 89.1.1.42. Di conseguenza, ipAdEntNetMask.89.1.1.42 identificherebbe l'istanza desiderata.

3.2.6.3.4. Nomi dei tipi di oggetto ipRoutingTable​

Il nome di una rotta IP, x, è OBJECT IDENTIFIER nella forma a.b.c.d tale che a.b.c.d è il valore (nella familiare notazione "punto") di quell'istanza del tipo di oggetto ipRouteDest associato a x.

Per ogni tipo di oggetto, t, per il quale il nome definito, n, ha il prefisso ipRoutingEntry, un'istanza, i, di t è denominata da un OBJECT IDENTIFIER della forma n.y, dove y è il nome della rotta IP su cui i rappresenta le informazioni.

Ad esempio, si supponga di voler trovare l'hop successivo di una voce nella tabella di instradamento IP associata alla destinazione 89.1.1.42. Di conseguenza, ipRouteNextHop.89.1.1.42 identificherebbe l'istanza desiderata.

3.2.6.3.5. Nomi dei tipi di oggetto tcpConnTable​

Il nome di una connessione TCP, x, è OBJECT IDENTIFIER nella forma a.b.c.d.e.f.g.h.i.j tale che a.b.c.d è il valore (nella familiare notazione "punto") di quell'istanza del tipo di oggetto tcpConnLocalAddress associato a x e tale che f.g.h.i è il valore (nella familiare notazione "punto") di quell'istanza del tipo di oggetto tcpConnRemoteAddress associato a x e tale che e sia il valore di quell'istanza del tipo di oggetto tcpConnLocalPort associato a x e tale che j sia il valore di quell'istanza del tipo di oggetto tcpConnRemotePort associato a x.

Per ciascun tipo di oggetto, t, per il quale il nome definito, n, ha il prefisso tcpConnEntry, un'istanza, i, di t è denominata da un OBJECT IDENTIFIER della forma n.y, dove y è il nome della connessione TCP su cui i rappresenta le informazioni.

Ad esempio, si supponga di voler trovare lo stato di una connessione TCP tra l'indirizzo locale di 89.1.1.42 sulla porta 21 TCP e l'indirizzo remoto di 10.0.0.51 sulla porta 2059 TCP. Di conseguenza, tcpConnState.89.1.1.42.21.10.0.0.51.2059 identificherebbe l'istanza desiderata.

3.2.6.3.6. Nomi dei tipi di oggetto egpNeighTable​

Il nome di un vicino EGP, x, è OBJECT IDENTIFIER nella forma a.b.c.d tale che a.b.c.d è il valore (nella familiare notazione "punto") di quell'istanza del tipo di oggetto egpNeighAddr associato a x.

Per ogni tipo di oggetto, t, per il quale il nome definito, n, ha il prefisso egpNeighEntry, un'istanza, i, di t è denominata da un OBJECT IDENTIFIER della forma n.y, dove y è il nome del vicino EGP su cui i rappresenta le informazioni.

Ad esempio, supponiamo di voler trovare lo stato vicino per l'indirizzo IP di 89.1.1.42. Di conseguenza, egpNeighState.89.1.1.42 identificherebbe l'istanza desiderata.

4. Specifica del protocollo​

Il protocollo di gestione della rete è un protocollo applicativo mediante il quale è possibile controllare o modificare le variabili dell'MIB di un agente.

La comunicazione tra entità del protocollo avviene tramite lo scambio di messaggi, ciascuno dei quali è interamente e indipendentemente rappresentato all'interno di un singolo datagramma UDP utilizzando le regole di codifica di base di ASN.1 (come discusso nella Sezione 3.2.2). Un messaggio è costituito da un identificatore di versione, un nome di comunità SNMP e un'unità dati di protocollo (PDU). Un'entità di protocollo riceve messaggi sulla porta 161 UDP sull'host a cui è associata per tutti i messaggi tranne quelli che riportano trap (ovvero tutti i messaggi tranne quelli che contengono Trap-PDU). I messaggi che riportano trap devono essere ricevuti sulla porta 162 UDP per un'ulteriore elaborazione. Un'implementazione di questo protocollo non necessita di accettare messaggi la cui lunghezza supera i 484 ottetti. Tuttavia, si consiglia che le implementazioni supportino datagrammi più grandi quando possibile.

È obbligatorio che tutte le implementazioni di SNMP supportino le cinque PDU: GetRequest-PDU, GetNextRequest-PDU, GetResponse-PDU, SetRequest-PDU e Trap-PDU.

    RFC1157-SNMP DEFINITIONS ::= BEGIN

     IMPORTS
          ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks
                  FROM RFC1155-SMI;

     -- top-level message

             Message ::=
                     SEQUENCE {
                          version        -- version-1 for this RFC
                             INTEGER {
                                 version-1(0)
                             },

                         community      -- community name
                             OCTET STRING,

                         data           -- e.g., PDUs if trivial
                             ANY        -- authentication is being used
                     }
     -- protocol data units

             PDUs ::=
                     CHOICE {
                         get-request
                             GetRequest-PDU,

                         get-next-request
                             GetNextRequest-PDU,

                         get-response
                             GetResponse-PDU,

                         set-request
                             SetRequest-PDU,

                         trap
                             Trap-PDU
                          }

     -- the individual PDUs and commonly used
     -- data types will be defined later

     END

4.1. Elementi di procedura​

Questa sezione descrive le azioni di un'entità di protocollo che implementa SNMP. Si noti, tuttavia, che non è inteso vincolare l'architettura interna di alcuna implementazione conforme.

Nel testo che segue viene utilizzato il termine indirizzo di trasporto. Nel caso di UDP, un indirizzo di trasporto è costituito da un indirizzo IP insieme a una porta UDP. Altri servizi di trasporto possono essere utilizzati per supportare SNMP. In questi casi, la definizione di un indirizzo di trasporto dovrebbe essere fatta di conseguenza.

Le azioni di primo livello di un'entità di protocollo che genera un messaggio sono le seguenti:

  1. Innanzitutto costruisce la PDU appropriata, ad esempio GetRequest-PDU, come oggetto ASN.1.

  2. Quindi passa questo oggetto ASN.1 insieme a un nome di comunità, al suo indirizzo di trasporto di origine e all'indirizzo di trasporto di destinazione, al servizio che implementa lo schema di autenticazione desiderato. Questo servizio di autenticazione restituisce un altro oggetto ASN.1.

  3. L'entità del protocollo costruisce quindi un oggetto messaggio ASN.1, utilizzando il nome della comunità e l'oggetto ASN.1 risultante.

  4. Questo nuovo oggetto ASN.1 viene quindi serializzato, utilizzando le regole di codifica di base di ASN.1, e quindi inviato utilizzando un servizio di trasporto all'entità del protocollo peer.

Allo stesso modo, le azioni di primo livello di un'entità di protocollo che riceve un messaggio sono le seguenti:

  1. Esegue un'analisi rudimentale del datagramma in entrata per costruire un oggetto ASN.1 corrispondente a un oggetto Messaggio ASN.1. Se l'analisi fallisce, scarta il datagramma e non esegue ulteriori azioni.

  2. Quindi verifica il numero di versione del messaggio SNMP. Se c'è una mancata corrispondenza, scarta il datagramma e non esegue ulteriori azioni.

  3. L'entità del protocollo passa quindi il nome della comunità e i dati dell'utente trovati nell'oggetto Message ASN.1, insieme agli indirizzi di trasporto di origine e destinazione del datagramma al servizio che implementa lo schema di autenticazione desiderato. Questa entità restituisce un altro oggetto ASN.1 o segnala un errore di autenticazione. In quest'ultimo caso, l'entità del protocollo rileva questo errore, (eventualmente) genera una trappola, scarta il datagramma e non esegue ulteriori azioni.

  4. L'entità del protocollo esegue quindi un'analisi rudimentale sull'oggetto ASN.1 restituito dal servizio di autenticazione per creare un oggetto ASN.1 corrispondente a un oggetto PDU ASN.1. Se l'analisi fallisce, scarta il datagramma e non esegue ulteriori azioni. Altrimenti, utilizzando la comunità denominata SNMP, viene selezionato il profilo appropriato e la PDU viene elaborata di conseguenza. Se, come risultato di questa elaborazione, viene restituito un messaggio, l'indirizzo di trasporto di origine da cui viene inviato il messaggio di risposta sarà identico all'indirizzo di trasporto di destinazione a cui è stato inviato il messaggio di richiesta originale.

4.1.1. Strutture comuni​

Prima di introdurre le sei tipologie di PDU del protocollo, è opportuno considerare alcuni dei costrutti ASN.1 utilizzati frequentemente:

                  -- request/response information
                  RequestID ::=
                          INTEGER
                  ErrorStatus ::=
                          INTEGER {
                              noError(0),
                              tooBig(1),
                              noSuchName(2),
                              badValue(3),
                              readOnly(4)
                              genErr(5)
                          }
                  ErrorIndex ::=
                          INTEGER
                  -- variable bindings
                  VarBind ::=
                          SEQUENCE {
                              name
                                  ObjectName,

                              value
                                  ObjectSyntax
                          }
                  VarBindList ::=
                          SEQUENCE OF
                              VarBind

I RequestID vengono utilizzati per distinguere tra le richieste in sospeso. Utilizzando RequestID, un'entità dell'applicazione SNMP può correlare le risposte in arrivo con le richieste in sospeso. Nei casi in cui viene utilizzato un servizio di datagramma inaffidabile, RequestID fornisce anche un semplice mezzo per identificare i messaggi duplicati dalla rete.

Un'istanza diversa da zero di ErrorStatus viene utilizzata per indicare che si è verificata un'eccezione durante l'elaborazione di una richiesta. In questi casi, ErrorIndex può fornire informazioni aggiuntive indicando quale variabile in un elenco ha causato l'eccezione.

Il termine variabile si riferisce a un'istanza di un oggetto gestito. Un'associazione di variabile, o VarBind, si riferisce all'abbinamento del nome di una variabile al valore della variabile. Una VarBindList è un semplice elenco di nomi di variabili e valori corrispondenti. Alcune PDU riguardano solo il nome di una variabile e non il suo valore (ad esempio, GetRequest-PDU). In questo caso, la parte valore dell'associazione viene ignorata dall'entità del protocollo. Tuttavia, la parte del valore deve ancora avere una sintassi e una codifica ASN.1 valide. Si consiglia di utilizzare il valore ASN.1 NULL per la parte del valore di tali associazioni.

4.1.2. GetRequest-PDU​

La forma dell'GetRequest-PDU è:

                  GetRequest-PDU ::=
                      [0]
                          IMPLICIT SEQUENCE {
                              request-id
                                  RequestID,

                              error-status        -- always 0
                                  ErrorStatus,

                              error-index         -- always 0
                                  ErrorIndex,

                              variable-bindings
                                  VarBindList
                          }

L'GetRequest-PDU viene generato da un'entità di protocollo solo su richiesta della sua entità applicativa SNMP.

Al ricevimento del GetRequest-PDU, l'entità del protocollo ricevente risponde in base a qualsiasi regola applicabile nell'elenco seguente:

  1. Se, per qualsiasi oggetto denominato nel campo variable-bindings, il nome dell'oggetto non corrisponde esattamente al nome di qualche oggetto disponibile per le operazioni get nella relativa vista MIB, l'entità ricevente invia all'originatore del messaggio ricevuto GetResponse-PDU di forma identica, tranne per il fatto che il valore del campo error-status è noSuchName e il valore del Il campo error-index è l'indice di detto componente del nome oggetto nel messaggio ricevuto.

  2. Se, per qualsiasi oggetto denominato nel campo variable-bindings, l'oggetto è di tipo aggregato (come definito in SMI), l'entità ricevente invia all'originatore del messaggio ricevuto GetResponse-PDU di forma identica, tranne per il fatto che il valore del campo error-status è noSuchName e il valore del campo error-index è l'indice del nome di detto oggetto componente nel messaggio ricevuto.

  3. Se la dimensione del GetResponse-PDU generato come descritto di seguito supera un limite locale, l'entità ricevente invia all'originatore del messaggio ricevuto GetResponse-PDU di forma identica, tranne che il valore del campo error-status è tooBig e il valore del campo error-index è zero.

  4. Se, per qualsiasi oggetto nominato nel campo variable-bindings, il valore dell'oggetto non può essere recuperato per ragioni non coperte da nessuna delle regole precedenti, allora l'entità ricevente invia all'originatore del messaggio ricevuto il GetResponse-PDU di forma identica, tranne che il valore del campo error-status è genErr e il valore del campo error-index è l'indice di detto nome oggetto componente nel messaggio ricevuto.

Se nessuna delle regole precedenti si applica, allora l'entità del protocollo ricevente invia all'originatore del messaggio ricevuto GetResponse-PDU in modo tale che, per ciascun oggetto nominato nel campo dei collegamenti delle variabili del messaggio ricevuto, il componente corrispondente del GetResponse-PDU rappresenta il nome e il valore di quella variabile. Il valore del campo stato errore della GetResponse-PDU è noError e il valore del campo error-index è zero. Il valore del campo request-id del GetResponse-PDU è quello del messaggio ricevuto.

4.1.3. GetNextRequest-PDU​

La forma dell'GetNextRequest-PDU è identica a quella dell'GetRequest-PDU fatta eccezione per l'indicazione del tipo di PDU. Nella lingua ASN.1:

                  GetNextRequest-PDU ::=
                      [1]
                          IMPLICIT SEQUENCE {
                              request-id
                                  RequestID,
                              error-status        -- always 0
                                  ErrorStatus,

                              error-index         -- always 0
                                  ErrorIndex,

                              variable-bindings
                                  VarBindList
                          }

L'GetNextRequest-PDU viene generato da un'entità di protocollo solo su richiesta della sua entità applicativa SNMP.

Al ricevimento del GetNextRequest-PDU, l'entità del protocollo ricevente risponde in base a qualsiasi regola applicabile nell'elenco seguente:

  1. Se, per qualsiasi nome di oggetto nel campo variable-bindings, quel nome non precede lessicograficamente il nome di qualche oggetto disponibile per le operazioni get nella relativa vista MIB, allora l'entità ricevente invia all'originatore del messaggio ricevuto il GetResponse-PDU di forma identica, tranne che il valore del campo error-status è noSuchName, e il valore del Il campo error-index è l'indice di detto componente del nome oggetto nel messaggio ricevuto.

  2. Se la dimensione del GetResponse-PDU generato come descritto di seguito supera un limite locale, l'entità ricevente invia all'originatore del messaggio ricevuto GetResponse-PDU di forma identica, tranne che il valore del campo error-status è tooBig e il valore del campo error-index è zero.

  3. Se, per qualsiasi oggetto nominato nel campo variable-bindings, il valore del successore lessicografico dell'oggetto nominato non può essere recuperato per ragioni non coperte da nessuna delle regole precedenti, allora l'entità ricevente invia all'originatore del messaggio ricevuto il GetResponse-PDU di forma identica, tranne che il valore del campo error-status è genErr e il valore del Il campo error-index è l'indice di detto componente del nome oggetto nel messaggio ricevuto.

Se non si applica nessuna delle regole precedenti, allora l'entità del protocollo ricevente invia all'originatore del messaggio ricevuto GetResponse-PDU in modo tale che, per ciascun nome nel campo variable-bindings del messaggio ricevuto, il componente corrispondente del GetResponse-PDU rappresenta il nome e il valore di quell'oggetto il cui nome è, nell'ordine lessicografico dei nomi di tutti gli oggetti disponibili per le operazioni get nella relativa vista MIB, insieme al valore del campo nome del dato componente, l'immediato successore di quel valore. Il valore del campo error-status di GetResponse-PDU è noError e il valore del campo errorindex è zero. Il valore del campo request-id del GetResponse-PDU è quello del messaggio ricevuto.

4.1.3.1. Esempio di attraversamento della tabella​

Un uso importante dell'GetNextRequest-PDU è l'attraversamento delle tabelle concettuali di informazioni all'interno dell'MIB. La semantica di questo tipo di messaggio SNMP, insieme ai meccanismi specifici del protocollo per identificare singole istanze dei tipi di oggetto nell'MIB, consente l'accesso agli oggetti correlati nell'MIB come se godessero di un'organizzazione tabellare.

Con lo scambio SNMP illustrato di seguito, un'entità applicativa SNMP potrebbe estrarre l'indirizzo di destinazione e il gateway dell'hop successivo per ciascuna voce nella tabella di instradamento di un particolare elemento di rete. Supponiamo che questa tabella di routing abbia tre voci:

         Destination                     NextHop         Metric
         10.0.0.99                       89.1.1.42       5
         9.1.2.3                         99.0.0.3        3
         10.0.0.51                       89.1.1.42       5

La stazione di gestione invia all'agente SNMP un GetNextRequest-PDU contenente i valori OBJECT IDENTIFIER indicati come nomi delle variabili richieste:

   GetNextRequest ( ipRouteDest, ipRouteNextHop, ipRouteMetric1 )

L'agente SNMP risponde con un GetResponse-PDU:

                 GetResponse (( ipRouteDest.9.1.2.3 =  "9.1.2.3" ),
                         ( ipRouteNextHop.9.1.2.3 = "99.0.0.3" ),
                         ( ipRouteMetric1.9.1.2.3 = 3 ))

La postazione di gestione prosegue con:

                 GetNextRequest ( ipRouteDest.9.1.2.3,
                         ipRouteNextHop.9.1.2.3,
                         ipRouteMetric1.9.1.2.3 )

L'agente SNMP risponde:

                 GetResponse (( ipRouteDest.10.0.0.51 = "10.0.0.51" ),
                         ( ipRouteNextHop.10.0.0.51 = "89.1.1.42" ),
                         ( ipRouteMetric1.10.0.0.51 = 5 ))

La postazione di gestione prosegue con:

                 GetNextRequest ( ipRouteDest.10.0.0.51,
                         ipRouteNextHop.10.0.0.51,
                         ipRouteMetric1.10.0.0.51 )

L'agente SNMP risponde:

                 GetResponse (( ipRouteDest.10.0.0.99 = "10.0.0.99" ),
                         ( ipRouteNextHop.10.0.0.99 = "89.1.1.42" ),
                         ( ipRouteMetric1.10.0.0.99 = 5 ))

La postazione di gestione prosegue con:

                 GetNextRequest ( ipRouteDest.10.0.0.99,
                         ipRouteNextHop.10.0.0.99,
                         ipRouteMetric1.10.0.0.99 )

Poiché nella tabella non sono presenti ulteriori voci, l'agente SNMP restituisce gli oggetti che sono i successivi nell'ordine lessicografico dei nomi di oggetti conosciuti. Questa risposta segnala alla stazione di gestione la fine della tabella di instradamento.

4.1.4. GetResponse-PDU​

La forma del GetResponse-PDU è identica a quella dell'GetRequest-PDU fatta eccezione per l'indicazione del tipo di PDU. Nella lingua ASN.1:

                  GetResponse-PDU ::=
                      [2]
                          IMPLICIT SEQUENCE {
                              request-id
                                  RequestID,
                              error-status
                                  ErrorStatus,

                              error-index
                                  ErrorIndex,

                              variable-bindings
                                  VarBindList
                          }

GetResponse-PDU viene generato da un'entità di protocollo solo al ricevimento di GetRequest-PDU, GetNextRequest-PDU o SetRequest-PDU, come descritto altrove in questo documento.

Al ricevimento del GetResponse-PDU, l'entità del protocollo ricevente presenta i suoi contenuti alla sua entità applicativa SNMP.

4.1.5. SetRequest-PDU​

La forma delSetRequest-PDU è identica a quella dell'GetRequest-PDU fatta eccezione per l'indicazione del tipo di PDU. Nella lingua ASN.1:

                  SetRequest-PDU ::=
                      [3]
                          IMPLICIT SEQUENCE {
                              request-id
                                  RequestID,

                              error-status        -- always 0
                                  ErrorStatus,

                              error-index         -- always 0
                                  ErrorIndex,

                              variable-bindings
                                  VarBindList
                          }

L'SetRequest-PDU viene generato da un'entità di protocollo solo su richiesta della sua entità applicativa SNMP.

Al ricevimento del SetRequest-PDU, l'entità ricevente risponde secondo qualsiasi regola applicabile nell'elenco seguente:

  1. Se, per qualsiasi oggetto denominato nel campo variable-bindings, l'oggetto non è disponibile per le operazioni di insieme nella relativa vista MIB, l'entità ricevente invia all'originatore del messaggio ricevuto GetResponse-PDU di forma identica, tranne per il fatto che il valore del campo error-status è noSuchName e il valore del campo error-index è l'indice di detto oggetto componente del nome nel messaggio ricevuto.

  2. Se, per qualsiasi oggetto denominato nel campo variable-bindings, il contenuto del campo valore non manifesta, secondo il linguaggio ASN.1, un tipo, una lunghezza e un valore coerenti con quelli richiesti per la variabile, allora l'entità ricevente invia all'originatore del messaggio ricevuto GetResponse-PDU di forma identica, tranne che il valore del campo error-status è badValue, e il il valore del campo error-index è l'indice del nome di detto oggetto nel messaggio ricevuto.

  3. Se la dimensione del messaggio di tipo Get Response generato come descritto di seguito supera un limite locale, l'entità ricevente invia all'originatore del messaggio ricevuto il messaggio GetResponse-PDU di forma identica, tranne per il fatto che il valore del campo error-status è tooBig e il valore del campo error-index è zero.

  4. Se, per qualsiasi oggetto nominato nel campo variable-bindings, il valore dell'oggetto nominato non può essere modificato per ragioni non coperte da nessuna delle regole precedenti, allora l'entità ricevente invia all'originatore del messaggio ricevuto il GetResponse-PDU di forma identica, tranne che il valore del campo error-status è genErr e il valore del campo error-index è l'indice di detto oggetto componente del nome nel messaggio ricevuto.

Se non si applica nessuna delle regole precedenti, allora per ogni oggetto nominato nel campo variable-bindings del messaggio ricevuto, alla variabile viene assegnato il valore corrispondente. Ciascuna assegnazione di variabile specificata da SetRequest-PDU deve essere effettuata come se fosse impostata contemporaneamente rispetto a tutte le altre assegnazioni specificate nello stesso messaggio.

L'entità ricevente invia quindi all'originatore del messaggio ricevuto il GetResponse-PDU di forma identica tranne che il valore del campo error-status del messaggio generato è noError e il valore del campo error-index è zero.

4.1.6. Trap-PDU​

La forma di Trap-PDU è:

     Trap-PDU ::=
         [4]

              IMPLICIT SEQUENCE {
                 enterprise          -- type of object generating
                                     -- trap, see sysObjectID in [5]
                     OBJECT IDENTIFIER,

                 agent-addr          -- address of object generating
                     NetworkAddress, -- trap

                 generic-trap        -- generic trap type
                     INTEGER {
                         coldStart(0),
                         warmStart(1),
                         linkDown(2),
                         linkUp(3),
                         authenticationFailure(4),
                         egpNeighborLoss(5),
                         enterpriseSpecific(6)
                     },

                 specific-trap     -- specific code, present even
                     INTEGER,      -- if generic-trap is not
                                   -- enterpriseSpecific

                 time-stamp        -- time elapsed between the last
                   TimeTicks,      -- (re)initialization of the network
                                   -- entity and the generation of the
                                      trap

                 variable-bindings   -- "interesting" information
                      VarBindList
             }

L'Trap-PDU viene generato da un'entità di protocollo solo su richiesta dell'entità applicativa SNMP. Il mezzo con cui un'entità dell'applicazione SNMP seleziona gli indirizzi di destinazione delle entità dell'applicazione SNMP è specifico dell'implementazione.

Al ricevimento di Trap-PDU, l'entità del protocollo ricevente presenta i suoi contenuti alla sua entità applicativa SNMP. Il significato del componente variable-bindings di Trap-PDU è specifico dell'implementazione.

Le interpretazioni del valore del campo generic-trap sono:

4.1.6.1. Trap coldStart​

Una trap coldStart(0) indica che l'entità del protocollo di invio si sta reinizializzando in modo tale che la configurazione dell'agente o l'implementazione dell'entità del protocollo potrebbe essere modificata.

4.1.6.2. Trap warmStart​

Una trap warmStart(1) indica che l'entità del protocollo di invio si sta reinizializzando in modo tale che né la configurazione dell'agente né l'implementazione dell'entità del protocollo vengano alterate.

4.1.6.3. Trap linkDown​

Una trap linkDown(2) indica che l'entità del protocollo di invio riconosce un errore in uno dei collegamenti di comunicazione rappresentati nella configurazione dell'agente.

L'Trap-PDU di tipo linkDown contiene come primo elemento del suo variable-bindings, il nome e il valore dell'istanza ifIndex per l'interfaccia interessata.

4.1.6.4. Trap linkUp​

Una trap linkUp(3) significa che l'entità del protocollo di invio riconosce che uno dei collegamenti di comunicazione rappresentati nella configurazione dell'agente è attivo.

L'Trap-PDU di tipo linkUp contiene come primo elemento del suo variable-bindings, il nome e il valore dell'istanza ifIndex per l'interfaccia interessata.

4.1.6.5. Trap authenticationFailure​

Una trap authenticationFailure(4) indica che l'entità del protocollo mittente è il destinatario di un messaggio di protocollo non autenticato correttamente. Sebbene le implementazioni di SNMP debbano essere in grado di generare questa trappola, devono anche essere in grado di sopprimere l'emissione di tali trappole tramite un meccanismo specifico dell'implementazione.

4.1.6.6. Trap egpNeighborLoss​

Una trap egpNeighborLoss(5) significa che un vicino EGP per il quale l'entità del protocollo di invio era un peer EGP è stato contrassegnato e la relazione peer non è più valida.

L'Trap-PDU di tipo egpNeighborLoss contiene come primo elemento del suo variable-bindings, il nome e il valore dell'istanza egpNeighAddr per il vicino interessato.

4.1.6.7. Trap enterpriseSpecific​

Una trap enterpriseSpecific(6) indica che l'entità del protocollo di invio riconosce che si è verificato un evento specifico dell'azienda. Il campo specific-trap identifica la particolare trappola che si è verificata.

5. Definizioni​

     RFC1157-SNMP DEFINITIONS ::= BEGIN

      IMPORTS
          ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks
              FROM RFC1155-SMI;

          -- top-level message

          Message ::=
                  SEQUENCE {
                      version          -- version-1 for this RFC
                          INTEGER {
                              version-1(0)
                          },

                      community        -- community name
                          OCTET STRING,

                      data             -- e.g., PDUs if trivial
                          ANY          -- authentication is being used
                  }

          -- protocol data units

          PDUs ::=
                  CHOICE {
                              get-request
                                  GetRequest-PDU,

                              get-next-request
                                  GetNextRequest-PDU,

                              get-response
                                  GetResponse-PDU,

                              set-request
                                  SetRequest-PDU,

                              trap
                                  Trap-PDU
                          }
          -- PDUs

          GetRequest-PDU ::=
              [0]
                  IMPLICIT PDU

          GetNextRequest-PDU ::=
              [1]
                  IMPLICIT PDU

          GetResponse-PDU ::=
              [2]
                  IMPLICIT PDU

          SetRequest-PDU ::=
              [3]
                  IMPLICIT PDU

          PDU ::=
                  SEQUENCE {
                     request-id
                          INTEGER,

                      error-status      -- sometimes ignored
                          INTEGER {
                              noError(0),
                              tooBig(1),
                              noSuchName(2),
                              badValue(3),
                              readOnly(4),
                              genErr(5)
                          },

                      error-index       -- sometimes ignored
                         INTEGER,

                      variable-bindings -- values are sometimes ignored
                          VarBindList
                  }

          Trap-PDU ::=
              [4]
                 IMPLICIT SEQUENCE {
                      enterprise        -- type of object generating
                                        -- trap, see sysObjectID in [5]

                          OBJECT IDENTIFIER,
                      agent-addr        -- address of object generating
                          NetworkAddress, -- trap

                      generic-trap      -- generic trap type
                          INTEGER {
                              coldStart(0),
                              warmStart(1),
                              linkDown(2),
                              linkUp(3),
                              authenticationFailure(4),
                              egpNeighborLoss(5),
                              enterpriseSpecific(6)
                          },

                      specific-trap  -- specific code, present even
                          INTEGER,   -- if generic-trap is not
                                     -- enterpriseSpecific

                      time-stamp     -- time elapsed between the last
                          TimeTicks, -- (re)initialization of the
                                        network
                                     -- entity and the generation of the
                                        trap

                       variable-bindings -- "interesting" information
                          VarBindList
                  }

          -- variable bindings

          VarBind ::=
                  SEQUENCE {
                      name
                          ObjectName,

                      value
                          ObjectSyntax
                  }

         VarBindList ::=
                  SEQUENCE OF
                     VarBind

         END

6. Ringraziamenti​

Questo memo è stato influenzato dal gruppo di lavoro Estensioni IETF SNMP:

      Karl Auerbach, Epilogue Technology
      K. Ramesh Babu, Excelan
      Amatzia Ben-Artzi, 3Com/Bridge
      Lawrence Besaw, Hewlett-Packard
      Jeffrey D. Case, University of Tennessee at Knoxville
      Anthony Chung, Sytek
      James Davidson, The Wollongong Group
      James R. Davin, MIT Laboratory for Computer Science
      Mark S. Fedor, NYSERNet
      Phill Gross, The MITRE Corporation
      Satish Joshi, ACC
      Dan Lynch, Advanced Computing Environments
      Keith McCloghrie, The Wollongong Group
      Marshall T. Rose, The Wollongong Group (chair)
      Greg Satz, cisco
      Martin Lee Schoffstall, Rensselaer Polytechnic Institute
      Wengyik Yeong, NYSERNet

7. Riferimenti​

[1] Cerf, V., "IAB Recommendations for the Development of Internet Network Management Standards", RFC 1052, IAB, April 1988.

[2] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", RFC 1065, TWG, August 1988.

[3] McCloghrie, K., and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets", RFC 1066, TWG, August 1988.

[4] Cerf, V., "Report of the Second Ad Hoc Network Management Review Group", RFC 1109, IAB, August 1989.

[5] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", RFC 1155, Performance Systems International and Hughes LAN Systems, May 1990.

[6] McCloghrie, K., and M. Rose, "Management Information Base for Network Management of TCP/IP-based Internets", RFC 1156, Hughes LAN Systems and Performance Systems International, May 1990.

[7] Case, J., M. Fedor, M. Schoffstall, and J. Davin, "A Simple Network Management Protocol", Internet Engineering Task Force working note, Network Information Center, SRI International, Menlo Park, California, March 1988.

[8] Davin, J., J. Case, M. Fedor, and M. Schoffstall, "A Simple Gateway Monitoring Protocol", RFC 1028, Proteon, University of Tennessee at Knoxville, Cornell University, and Rensselaer Polytechnic Institute, November 1987.

[9] Information processing systems - Open Systems Interconnection, "Specification of Abstract Syntax Notation One (ASN.1)", International Organization for Standardization, International Standard 8824, December 1987.

[10] Information processing systems - Open Systems Interconnection, "Specification of Basic Encoding Rules for Abstract Notation One (ASN.1)", International Organization for Standardization, International Standard 8825, December 1987.

[11] Postel, J., "User Datagram Protocol", RFC 768, USC/Information Sciences Institute, November 1980.

8. Considerazioni sulla sicurezza​

Le questioni di sicurezza non sono discusse in questo memorandum.

9. Indirizzi degli autori​

Jeffrey D. Case SNMP Research P.O. Box 8593 Knoxville, TN 37996-4800

Telefono: (615) 573-1434

Email: [email protected]

Mark Fedor Performance Systems International Rensselaer Technology Park 125 Jordan Road Troy, NY 12180

Telefono: (518) 283-8860

Email: [email protected]

Martin Lee Schoffstall Performance Systems International Rensselaer Technology Park 165 Jordan Road Troy, NY 12180

Telefono: (518) 283-8860

Email: [email protected] James R. Davin MIT Laboratory for Computer Science, NE43-507 545 Technology Square Cambridge, MA 02139

Telefono: (617) 253-6020

Email: [email protected]

Ultimo aggiornamento il