9. Contabilizzazione (Accounting)

Il presente protocollo di contabilizzazione si basa su un modello guidato dal server (server directed model) con capacità di consegna in tempo reale delle informazioni di contabilizzazione. Nel protocollo sono stati integrati diversi metodi di resilienza ai guasti [RFC2975] per ridurre al minimo la perdita di dati di contabilizzazione in vari scenari di errore e in base a ipotesi diverse sulle capacità dei dispositivi utilizzati.

9.1. Modello guidato dal server (Server Directed Model)

Il modello guidato dal server significa che il dispositivo che genera i dati di contabilizzazione ottiene informazioni dal server di autorizzazione (se contattato) o dal server di contabilizzazione riguardo al modo in cui i dati devono essere inoltrati. Tali informazioni comprendono i requisiti di tempestività dei record di contabilizzazione.

Come discusso in [RFC2975], il trasferimento in tempo reale dei record è un requisito, ad esempio per controlli sul limite di credito e rilevamento frodi. La contabilizzazione in batch non è un requisito e pertanto non è supportata da Diameter. Se in futuro fosse necessaria la contabilizzazione in batch, andrebbe creata una nuova applicazione Diameter oppure si potrebbe usare un altro protocollo. Tuttavia, anche se a livello Diameter le richieste di contabilizzazione sono elaborate una alla volta, i protocolli di trasporto sottostanti in condizioni di traffico elevato raggruppano spesso più richieste nello stesso pacchetto, il che può essere sufficiente per molte applicazioni.

La catena di server di autorizzazione dirige la scelta della strategia di trasferimento appropriata in base alla conoscenza dell'utente e alle relazioni di roaming tra partner. Il server (o gli agenti) utilizza le AVP Acct-Interim-Interval e Accounting-Realtime-Required per controllare il funzionamento del peer Diameter che opera come client. Quando è presente, l'AVP Acct-Interim-Interval indica al nodo Diameter in veste di client di produrre record di contabilizzazione in modo continuo anche durante una sessione. L'AVP Accounting-Realtime-Required controlla il comportamento del client quando il trasferimento dei record dal client Diameter è ritardato o non riesce.

Il server di contabilizzazione Diameter PUÒ sovrascrivere l'intervallo intermedio o i requisiti in tempo reale includendo l'AVP Acct-Interim-Interval o Accounting-Realtime-Required nel messaggio Accounting-Answer. Quando una di queste AVP è presente, DOVREBBE essere usato il valore più recente ricevuto per le ulteriori attività di contabilizzazione della stessa sessione.

9.2. Messaggi del protocollo (Protocol Messages)

Un nodo Diameter che riceve un messaggio di autenticazione e/o autorizzazione con esito positivo dal server Diameter DOVREBBE raccogliere le informazioni di contabilizzazione per la sessione. Il messaggio Accounting-Request trasmette tali informazioni al server Diameter, che DEVE rispondere con il messaggio Accounting-Answer per confermare la ricezione. Il messaggio Accounting-Answer include l'AVP Result-Code, che PUÒ indicare la presenza di un errore nel messaggio di contabilizzazione. Il valore dell'AVP Accounting-Realtime-Required ricevuto in precedenza per la sessione in questione può indicare che la sessione dell'utente deve essere terminata quando viene ricevuto un messaggio Accounting-Request respinto.

9.3. Estensione dell'applicazione di contabilizzazione e requisiti (Accounting Application Extension and Requirements)

Ogni applicazione Diameter (ad es. NASREQ, Mobile IP) DOVREBBE definire le proprie AVP specifiche del servizio che DEVONO essere presenti nel messaggio Accounting-Request in una sezione intitolata «Accounting AVPs». L'applicazione DEVE presumere che le AVP descritte in questo documento saranno presenti in tutti i messaggi di contabilizzazione, pertanto in quella sezione occorre definire solo le rispettive AVP specifiche del servizio.

Le applicazioni possono usare uno o entrambi i seguenti modelli di estensione:

Servizio di contabilizzazione separato (Split Accounting Service)

Il messaggio di contabilizzazione porterà l'Application Id dell'applicazione di contabilizzazione di base Diameter (vedere la Sezione 2.4). I messaggi possono essere instradati verso nodi Diameter diversi dall'applicazione Diameter corrispondente. Tali nodi possono essere server di contabilizzazione centralizzati che forniscono il servizio a più applicazioni Diameter. Questi nodi DEVONO annunciare l'Application Id di contabilizzazione di base Diameter durante lo scambio delle capacità.

Servizio di contabilizzazione accoppiato (Coupled Accounting Service)

Il messaggio porterà l'Application Id dell'applicazione che lo utilizza. L'applicazione elaborerà i record ricevuti o li inoltrerà a un server di contabilizzazione. Non è richiesta alcuna segnalazione dell'applicazione di contabilizzazione durante lo scambio delle capacità, e i messaggi saranno instradati come gli altri messaggi di applicazione.

Nei casi in cui un'applicazione non definisce un proprio servizio di contabilizzazione, si preferisce il modello di contabilizzazione separato.

9.4. Resilienza ai guasti (Fault Resilience)

I meccanismi del protocollo base Diameter servono a superare piccole perdite di messaggi e guasti di rete temporanei.

I peer Diameter che operano come client DEVONO implementare il failover per proteggersi da guasti del server e da determinati guasti di rete. I peer che operano come agenti o i sistemi di elaborazione offline correlati DEVONO rilevare record di contabilizzazione duplicati causati dall'invio dello stesso record a più server e dalla duplicazione dei messaggi in transito. Il rilevamento DEVE basarsi sull'esame delle coppie Session-Id e Accounting-Record-Number. L'Appendice C tratta esigenze e questioni implementative del rilevamento dei duplicati.

I client Diameter POSSONO disporre di memoria non volatile per conservare in sicurezza i record durante riavvii, prolungati guasti di rete, partizioni di rete e guasti del server. Se tale memoria è disponibile, il client DOVREBBE archiviarvi i nuovi record non appena creati e fino al ricevimento di un riscontro positivo dal server Diameter. Dopo un riavvio, il client DEVE iniziare a inviare i record dalla memoria non volatile al server di contabilizzazione con le modifiche appropriate a causa di terminazione, durata della sessione e altre informazioni rilevanti.

Un'ulteriore applicazione di questo protocollo può includere AVP per controllare il numero massimo di record memorizzabili sul client Diameter senza confermarli in memoria non volatile o trasferirli al server Diameter.

Il client NON DOVREBBE rimuovere i dati di contabilizzazione da alcuna area di memoria prima di aver ricevuto l'Accounting-Answer corretto. Il client PUÒ rimuovere i dati più vecchi non consegnati o non ancora riscontrati se esaurisce risorse come la memoria. L'accettazione di nuove sessioni in questa condizione dipende dall'implementazione.

9.5. Record di contabilizzazione (Accounting Records)

In tutti i record di contabilizzazione l'AVP Session-Id DEVE essere presente; l'AVP User-Name DEVE essere presente se è disponibile al client Diameter.

A seconda del tipo effettivo di servizio contabilizzato e delle indicazioni del server di autorizzazione per la contabilizzazione intermedia, si inviano tipi diversi di record. Se il servizio è un evento una tantum, nel senso che inizio e fine sono simultanei, l'AVP Accounting-Record-Type DEVE essere presente e impostata al valore EVENT_RECORD.

Se il servizio ha durata misurabile, l'AVP DEVE usare i valori START_RECORD, STOP_RECORD e, se del caso, INTERIM_RECORD. Se il server di autorizzazione non ha abilitato la contabilizzazione intermedia per la sessione, DEVONO essere generati due record per ogni servizio di tipo sessione. Quando viene inviata la prima Accounting-Request per una data sessione, l'AVP Accounting-Record-Type DEVE essere START_RECORD. Quando viene inviata l'ultima Accounting-Request, il valore DEVE essere STOP_RECORD.

Se la contabilizzazione intermedia è abilitata, il client Diameter DEVE produrre record aggiuntivi tra START_RECORD e STOP_RECORD, contrassegnati come INTERIM_RECORD. La produzione è guidata da Acct-Interim-Interval nonché da eventuale ri-autenticazione o ri-autorizzazione della sessione. Il client Diameter DEVE sovrascrivere qualsiasi record intermedio precedentemente memorizzato localmente per la consegna se viene generato un nuovo record per la stessa sessione. Ciò garantisce che per ogni sessione esista al massimo un record intermedio in sospeso sul dispositivo di accesso.

Un particolare valore di Accounting-Sub-Session-Id DEVE comparire in una sola sequenza di record inviata da un client Diameter, salvo per la ritrasmissione. La sequenza inviata DEVE essere o un singolo record con Accounting-Record-Type uguale a EVENT_RECORD oppure più record che iniziano con START_RECORD, seguiti da zero o più INTERIM_RECORD e un solo STOP_RECORD. La specifica dell'applicazione Diameter interessata DEVE definire i tipi di sequenza da usare.

9.6. Correlazione dei record (Correlation of Accounting Records)

Se un'applicazione usa i messaggi di contabilizzazione, può correlare i record con una specifica sessione applicativa usando il Session-Id di quella sessione nei messaggi. I messaggi POSSONO anche usare un Session-Id diverso da quello delle sessioni applicative; in tal caso servono altre informazioni legate alla sessione per la correlazione.

Quando un'applicazione richiede più sotto-sessioni di contabilizzazione, si usa l'AVP Accounting-Sub-Session-Id per distinguerle. Il Session-Id resta costante per tutte le sotto-sessioni e serve a correlarle a una sessione applicativa. Notare che ricevere un STOP_RECORD senza AVP Accounting-Sub-Session-Id quando nelle START_RECORD erano state usate sotto-sessioni implica che tutte le sotto-sessioni sono terminate.

Vi sono anche casi in cui occorre correlare più sessioni applicative in un unico record di contabilizzazione; il record può estendersi su più applicazioni Diameter e sessioni usate dallo stesso utente in un dato istante. In tali casi si usa l'AVP Acct-Multi-Session-Id. L'AVP Acct-Multi-Session-Id DOVREBBE essere segnalata dal server al dispositivo di accesso (tipicamente durante l'autorizzazione) quando si determina che una richiesta appartiene a una sessione esistente. Il dispositivo di accesso DEVE quindi includere l'AVP Acct-Multi-Session-Id in tutti i messaggi di contabilizzazione successivi.

L'AVP Acct-Multi-Session-Id PUÒ includere il valore del Session-Id originale. Il contenuto è specifico dell'implementazione, ma DEVE essere globalmente unico rispetto agli altri Acct-Multi-Session-Id e NON DEVE cambiare per tutta la durata della sessione.

Un documento di applicazione Diameter DEVE definire il concetto esatto di sessione contabilizzata e PUÒ definire il concetto di multi-session. Ad esempio, l'applicazione NASREQ DIAMETER tratta una singola connessione PPP verso un NAS come una sessione e un insieme di sessioni Multilink PPP come una multi-session.

9.7. Codici di comando di contabilizzazione (Accounting Command Codes)

Questa sezione definisce i valori di codice di comando che DEVONO essere supportati da tutte le implementazioni Diameter che forniscono servizi di contabilizzazione.

9.7.1. Accounting-Request

Il comando Accounting-Request (ACR), indicato dal campo Command Code impostato a 271 e dal bit «R» dei Command Flags impostato, è inviato da un nodo Diameter in veste di client per scambiare informazioni di contabilizzazione con un peer.

Oltre alle AVP elencate di seguito, i messaggi Accounting-Request DOVREBBERO includere AVP di contabilizzazione specifiche del servizio.

Formato del messaggio (Message Format)

::= < Diameter Header: 271, REQ, PXY >
    < Session-Id >
    { Origin-Host }
    { Origin-Realm }
    { Destination-Realm }
    { Accounting-Record-Type }
    { Accounting-Record-Number }
    [ Acct-Application-Id ]
    [ Vendor-Specific-Application-Id ]
    [ User-Name ]
    [ Destination-Host ]
    [ Accounting-Sub-Session-Id ]
    [ Acct-Session-Id ]
    [ Acct-Multi-Session-Id ]
    [ Acct-Interim-Interval ]
    [ Accounting-Realtime-Required ]
    [ Origin-State-Id ]
    [ Event-Timestamp ]
    * [ Proxy-Info ]
    * [ Route-Record ]
    * [ AVP ]

9.7.2. Accounting-Answer

Il comando Accounting-Answer (ACA), indicato dal codice 271 e dal bit «R» azzerato, serve per confermare un Accounting-Request. Contiene lo stesso Session-Id della richiesta corrispondente.

Solo il server Diameter di destinazione, noto come home Diameter server, DOVREBBE rispondere con Accounting-Answer.

Oltre alle AVP elencate di seguito, i messaggi Accounting-Answer DOVREBBERO includere AVP di contabilizzazione specifiche del servizio.

Formato del messaggio (Message Format)

::= < Diameter Header: 271, PXY >
    < Session-Id >
    { Result-Code }
    { Origin-Host }
    { Origin-Realm }
    { Accounting-Record-Type }
    { Accounting-Record-Number }
    [ Acct-Application-Id ]
    [ Vendor-Specific-Application-Id ]
    [ User-Name ]
    [ Accounting-Sub-Session-Id ]
    [ Acct-Session-Id ]
    [ Acct-Multi-Session-Id ]
    [ Error-Message ]
    [ Error-Reporting-Host ]
    [ Failed-AVP ]
    [ Acct-Interim-Interval ]
    [ Accounting-Realtime-Required ]
    [ Origin-State-Id ]
    [ Event-Timestamp ]
    * [ Proxy-Info ]
    * [ AVP ]

9.8. AVP di contabilizzazione (Accounting AVPs)

Questa sezione contiene AVP che descrivono le informazioni di utilizzo contabilizzato relative a una sessione specifica.

9.8.1. Accounting-Record-Type AVP

L'AVP Accounting-Record-Type (codice AVP 480) è di tipo Enumerated e indica il tipo di record inviato. Sono attualmente definiti i seguenti valori:

EVENT_RECORD 1

Un record evento indica che si è verificato un evento una tantum (inizio e fine simultanei). Contiene tutte le informazioni rilevanti sul servizio ed è l'unico record del servizio.

START_RECORD 2

I record di avvio, intermedio e arresto indicano che è stato fornito un servizio di durata misurabile. Un record di avvio avvia una sessione di contabilizzazione e contiene informazioni pertinenti all'avvio.

INTERIM_RECORD 3

Un record intermedio contiene informazioni cumulative per una sessione di contabilizzazione esistente. I record intermedi DOVREBBERO essere inviati a ogni ri-autenticazione o ri-autorizzazione. Ulteriori trigger POSSONO essere definiti da applicazioni Diameter specifiche. La scelta di usare INTERIM_RECORD è determinata dall'AVP Acct-Interim-Interval.

STOP_RECORD 4

Un record di arresto termina la sessione di contabilizzazione e contiene informazioni cumulative pertinenti alla sessione esistente.

9.8.2. Acct-Interim-Interval AVP

L'AVP Acct-Interim-Interval (codice AVP 85) è di tipo Unsigned32 ed è inviata dal server di autorizzazione home Diameter al client Diameter. Il client usa le informazioni in questa AVP per decidere come e quando produrre i record. Con valori diversi, le sessioni di servizio possono produrre uno, due o 2+N record, in base alle esigenze dell'organizzazione home. Il comportamento seguente è determinato dalla presenza di questa AVP:

L'omissione dell'AVP Acct-Interim-Interval oppure un campo Value uguale a 0 significa che si producono EVENT_RECORD, START_RECORD e STOP_RECORD, come appropriato al servizio.
L'inclusione dell'AVP con Value diverso da zero significa che DEVONO essere prodotti record INTERIM_RECORD tra START_RECORD e STOP_RECORD. Il campo Value è l'intervallo nominale in secondi tra questi record. Il nodo Diameter che origina le informazioni di contabilizzazione, il client, DEVE produrre il primo INTERIM_RECORD circa quando dall'invio del START_RECORD è trascorso tale intervallo nominale, il successivo dopo un altro intervallo, e così via fino alla fine della sessione e all'invio del STOP_RECORD.

Il client DEVE randomizzare gli istanti di produzione dei record intermedi in modo da non creare grandi «tempeste» di messaggi di contabilizzazione tra i record o intorno a un istante comune di avvio del servizio.

9.8.3. Accounting-Record-Number AVP

L'AVP Accounting-Record-Number (codice AVP 485) è di tipo Unsigned32 e identifica il record all'interno di una sessione. Poiché le Session-Id sono globalmente uniche, anche la combinazione Session-Id e Accounting-Record-Number è globalmente unica e può essere usata per abbinare record e conferme. Un modo semplice è usare 0 per EVENT_RECORD e START_RECORD, 1 per il primo INTERIM_RECORD, 2 per il secondo, e così via, fino a STOP_RECORD uguale all'ultimo INTERIM_RECORD più uno.

9.8.4. Acct-Session-Id AVP

L'AVP Acct-Session-Id (codice AVP 44) è di tipo OctetString ed è usata solo quando avviene la traduzione RADIUS/Diameter. Contiene il contenuto dell'attributo RADIUS Acct-Session-Id.

9.8.5. Acct-Multi-Session-Id AVP

L'AVP Acct-Multi-Session-Id (codice AVP 50) è di tipo UTF8String, secondo il formato specificato nella Sezione 8.8. Serve a collegare più sessioni di contabilizzazione correlate, ciascuna con Session-Id univoco ma stessa Acct-Multi-Session-Id. Questa AVP PUÒ essere restituita dal server Diameter in una risposta di autorizzazione e DEVE essere usata in tutti i messaggi di contabilizzazione della sessione.

9.8.6. Accounting-Sub-Session-Id AVP

L'AVP Accounting-Sub-Session-Id (codice AVP 287) è di tipo Unsigned64 e contiene l'identificatore della sotto-sessione di contabilizzazione. La combinazione di Session-Id e questa AVP DEVE essere unica per sotto-sessione, e il valore di questa AVP DEVE aumentare monotonicamente di uno per ogni nuova sotto-sessione. L'assenza di questa AVP implica che non si usano sotto-sessioni, salvo per un Accounting-Request con Accounting-Record-Type impostato a STOP_RECORD. Un messaggio STOP_RECORD senza Accounting-Sub-Session-Id segnala la terminazione di tutte le sotto-sessioni per un dato Session-Id.

9.8.7. Accounting-Realtime-Required AVP

L'AVP Accounting-Realtime-Required (codice AVP 483) è di tipo Enumerated ed è inviata dal server di autorizzazione home Diameter al client Diameter oppure nell'Accounting-Answer dal server di contabilizzazione. Il client usa le informazioni in questa AVP per decidere cosa fare se l'invio dei record al server di contabilizzazione è stato temporaneamente impedito, ad esempio da un problema di rete.

DELIVER_AND_GRANT 1

Il valore DELIVER_AND_GRANT significa che il servizio DEVE essere concesso solo finché esiste una connessione verso un server di contabilizzazione. L'insieme di server di contabilizzazione alternativi è trattato come un unico server in questo senso. Il fatto di dover spostare il flusso di record su un server di backup non è motivo per interrompere il servizio all'utente.

GRANT_AND_STORE 2

Il valore GRANT_AND_STORE significa che il servizio DOVREBBE essere concesso se esiste una connessione, o finché i record possono ancora essere memorizzati come descritto nella Sezione 9.4.

Questo è il comportamento predefinito se l'AVP non è inclusa nella risposta del server di autorizzazione.

GRANT_AND_LOSE 3

Il valore GRANT_AND_LOSE significa che il servizio DOVREBBE essere concesso anche se i record non possono essere consegnati o memorizzati.