9. Comptabilisation (Accounting)

Ce protocole de comptabilisation repose sur un modèle dirigé par le serveur (server directed model) avec des capacités de livraison en temps réel des informations de comptabilisation. Plusieurs méthodes de résilience aux pannes [RFC2975] ont été intégrées au protocole afin de minimiser la perte de données de comptabilisation dans divers scénarios de défaillance et sous différentes hypothèses sur les capacités des équipements utilisés.

9.1. Modèle dirigé par le serveur (Server Directed Model)

Le modèle dirigé par le serveur signifie que l'équipement générant les données de comptabilisation obtient des informations, soit du serveur d'autorisation (s'il a été contacté), soit du serveur de comptabilisation, concernant la manière dont les données doivent être transmises. Ces informations comprennent les exigences de ponctualité des enregistrements de comptabilisation.

Comme indiqué dans [RFC2975], le transfert en temps réel des enregistrements est une exigence, par exemple pour les contrôles de plafond de crédit et la détection de fraude. Notez que la comptabilisation par lots n'est pas une exigence et n'est donc pas prise en charge par Diameter. Si une comptabilisation par lots devait être nécessaire à l'avenir, une nouvelle application Diameter devrait être créée, ou un autre protocole pourrait être utilisé. Notez toutefois que, même si au niveau Diameter les demandes de comptabilisation sont traitées une par une, les protocoles de transport sous-jacents regroupent généralement plusieurs demandes dans le même paquet en conditions de trafic élevé. Cela peut suffire pour de nombreuses applications.

La chaîne de serveurs d'autorisation oriente le choix de la stratégie de transfert appropriée, en fonction de sa connaissance de l'utilisateur et des relations de partenariat en itinérance. Le serveur (ou les agents) utilise les AVP Acct-Interim-Interval et Accounting-Realtime-Required pour contrôler le fonctionnement du pair Diameter agissant en tant que client. Lorsqu'elle est présente, l'AVP Acct-Interim-Interval indique au nœud Diameter agissant en tant que client de produire des enregistrements de comptabilisation en continu, y compris pendant une session. L'AVP Accounting-Realtime-Required contrôle le comportement du client lorsque le transfert des enregistrements depuis le client Diameter est retardé ou échoue.

Le serveur de comptabilisation Diameter PEUT remplacer l'intervalle intermédiaire ou les exigences temps réel en incluant l'AVP Acct-Interim-Interval ou Accounting-Realtime-Required dans le message Accounting-Answer. Lorsque l'une de ces AVP est présente, la dernière valeur reçue DEVRAIT être utilisée pour les activités de comptabilisation ultérieures de la même session.

9.2. Messages du protocole (Protocol Messages)

Un nœud Diameter qui reçoit un message d'authentification et/ou d'autorisation réussi du serveur Diameter DEVRAIT collecter les informations de comptabilisation pour la session. Le message Accounting-Request sert à transmettre ces informations au serveur Diameter, qui DOIT répondre par un message Accounting-Answer pour confirmer la réception. Le message Accounting-Answer inclut l'AVP Result-Code, qui PEUT indiquer qu'une erreur était présente dans le message de comptabilisation. La valeur de l'AVP Accounting-Realtime-Required reçue antérieurement pour la session concernée peut indiquer que la session de l'utilisateur doit être terminée lorsqu'un message Accounting-Request rejeté a été reçu.

9.3. Extension et exigences de l'application de comptabilisation (Accounting Application Extension and Requirements)

Chaque application Diameter (par ex. NASREQ, Mobile IP) DEVRAIT définir ses AVP spécifiques au service qui DOIVENT être présentes dans le message Accounting-Request, dans une section intitulée « Accounting AVPs ». L'application DOIT partir du principe que les AVP décrites dans le présent document seront présentes dans tous les messages de comptabilisation, de sorte que seules les AVP spécifiques au service respectif doivent être définies dans cette section.

Les applications peuvent utiliser l'un ou les deux modèles d'extension suivants :

Service de comptabilisation séparé (Split Accounting Service)

Le message de comptabilisation portera l'identifiant d'application (Application Id) de l'application de comptabilisation de base Diameter (voir la Section 2.4). Les messages peuvent être routés vers des nœuds Diameter autres que l'application Diameter correspondante. Il peut s'agir de serveurs de comptabilisation centralisés desservant plusieurs applications Diameter différentes. Ces nœuds DOIVENT annoncer l'Application Id de comptabilisation de base Diameter lors de l'échange de capacités.

Service de comptabilisation couplé (Coupled Accounting Service)

Le message portera l'Application Id de l'application qui l'utilise. L'application traitera elle-même les enregistrements reçus ou les transmettra à un serveur de comptabilisation. Aucune annonce d'application de comptabilisation n'est requise lors de l'échange de capacités, et les messages sont routés comme les autres messages d'application.

Lorsqu'une application ne définit pas son propre service de comptabilisation, il est préférable d'utiliser le modèle de comptabilisation séparé.

9.4. Résilience aux pannes (Fault Resilience)

Les mécanismes du protocole de base Diameter permettent de surmonter de petites pertes de messages et des pannes réseau temporaires.

Les pairs Diameter agissant en tant que clients DOIVENT mettre en œuvre le basculement (failover) pour se prémunir contre les défaillances de serveur et certaines pannes réseau. Les pairs agissant en tant qu'agents ou les systèmes de traitement hors ligne associés DOIVENT détecter les enregistrements dupliqués dus à l'envoi du même enregistrement vers plusieurs serveurs et à la duplication des messages en transit. Cette détection DOIT reposer sur l'examen des paires Session-Id et Accounting-Record-Number. L'Annexe C traite des besoins de détection des doublons et des questions d'implémentation.

Les clients Diameter PEUVENT disposer d'une mémoire non volatile pour stocker en toute sécurité les enregistrements lors de redémarrages, pannes réseau prolongées, partitions réseau ou défaillances de serveur. Si une telle mémoire est disponible, le client DEVRAIT y stocker les nouveaux enregistrements dès leur création et jusqu'à réception d'un accusé positif de la part du serveur Diameter. Après un redémarrage, le client DOIT commencer à envoyer les enregistrements stockés au serveur de comptabilisation, avec les modifications appropriées de la cause de terminaison, de la durée de session et d'autres informations pertinentes.

Une extension ultérieure du protocole peut inclure des AVP pour limiter le nombre maximal d'enregistrements stockés sur le client sans les valider en mémoire non volatile ni les transférer au serveur Diameter.

Le client NE DEVRAIT PAS supprimer les données de comptabilisation de ses zones mémoire avant d'avoir reçu le Accounting-Answer correct. Le client PEUT supprimer les données les plus anciennes non livrées ou non encore acquittées s'il manque de ressources telles que la mémoire. Le fait d'accepter de nouvelles sessions dans cette condition relève de l'implémentation.

9.5. Enregistrements de comptabilisation (Accounting Records)

Dans tous les enregistrements, l'AVP Session-Id DOIT être présente ; l'AVP User-Name DOIT être présente si elle est disponible pour le client Diameter.

Selon le type de service comptabilisé et les instructions du serveur d'autorisation pour la comptabilisation intermédiaire, différents types d'enregistrements sont envoyés. Si le service est un événement ponctuel, c'est-à-dire que le début et la fin sont simultanés, l'AVP Accounting-Record-Type DOIT être présente et fixée à la valeur EVENT_RECORD.

Si le service a une durée mesurable, l'AVP DOIT utiliser les valeurs START_RECORD, STOP_RECORD et éventuellement INTERIM_RECORD. Si le serveur d'autorisation n'a pas activé la comptabilisation intermédiaire pour la session, deux enregistrements DOIVENT être générés pour chaque service de type session. Lors de l'envoi du premier Accounting-Request pour une session donnée, l'AVP Accounting-Record-Type DOIT valoir START_RECORD. Lors du dernier Accounting-Request, la valeur DOIT être STOP_RECORD.

Si la comptabilisation intermédiaire est activée, le client Diameter DOIT produire des enregistrements supplémentaires entre START_RECORD et STOP_RECORD, marqués INTERIM_RECORD. Leur production est dirigée par Acct-Interim-Interval ainsi que par toute ré-authentification ou ré-autorisation de la session. Le client DOIT écraser tout enregistrement intermédiaire précédemment stocké localement pour livraison si un nouvel enregistrement est généré pour la même session. Ainsi, un seul enregistrement intermédiaire en attente peut exister sur un équipement d'accès pour une session donnée.

Une valeur particulière d'Accounting-Sub-Session-Id NE DOIT apparaître que dans une seule séquence d'enregistrements émise par un client Diameter, sauf aux fins de retransmission. Cette séquence DOIT être soit un seul enregistrement avec Accounting-Record-Type égal à EVENT_RECORD, soit plusieurs enregistrements commençant par START_RECORD, suivis de zéro ou plusieurs INTERIM_RECORD et d'un seul STOP_RECORD. La spécification de l'application Diameter concernée DOIT définir le type de séquences à utiliser.

9.6. Corrélation des enregistrements (Correlation of Accounting Records)

Si une application utilise les messages de comptabilisation, elle peut corréler les enregistrements avec une session d'application donnée en utilisant le Session-Id de cette session dans les messages. Les messages PEUVENT aussi utiliser un Session-Id différent de celui des sessions d'application, auquel cas d'autres informations liées à la session sont nécessaires pour la corrélation.

Lorsqu'une application exige plusieurs sous-sessions de comptabilisation, l'AVP Accounting-Sub-Session-Id différencie chaque sous-session. Le Session-Id reste constant pour toutes les sous-sessions et sert à les rattacher à une session d'application. Notez que la réception d'un STOP_RECORD sans AVP Accounting-Sub-Session-Id alors que des sous-sessions avaient été utilisées dans les messages START_RECORD implique que toutes les sous-sessions sont terminées.

Il existe aussi des cas où une application doit corréler plusieurs sessions d'application en un seul enregistrement de comptabilisation ; l'enregistrement peut couvrir plusieurs applications Diameter et sessions utilisées par le même utilisateur à un instant donné. Dans ce cas, on utilise l'AVP Acct-Multi-Session-Id. L'AVP Acct-Multi-Session-Id DEVRAIT être signalée par le serveur à l'équipement d'accès (typiquement lors de l'autorisation) lorsqu'il détermine qu'une demande appartient à une session existante. L'équipement d'accès DOIT alors inclure l'AVP Acct-Multi-Session-Id dans tous les messages de comptabilisation ultérieurs.

L'AVP Acct-Multi-Session-Id PEUT inclure la valeur du Session-Id d'origine. Son contenu est spécifique à l'implémentation, mais il DOIT être globalement unique par rapport aux autres Acct-Multi-Session-Id et NE DOIT PAS changer pendant la durée de vie de la session.

Un document d'application Diameter DOIT définir le concept exact de session comptabilisée et PEUT définir le concept de multi-session. Par exemple, l'application NASREQ considère une connexion PPP unique vers un NAS comme une session et un ensemble de sessions Multilink PPP comme une multi-session.

9.7. Codes de commande de comptabilisation (Accounting Command Codes)

Cette section définit les valeurs de code de commande qui DOIVENT être prises en charge par toute implémentation Diameter fournissant des services de comptabilisation.

9.7.1. Accounting-Request

La commande Accounting-Request (ACR), indiquée par le champ Code de commande fixé à 271 et le bit « R » des drapeaux de commande positionné, est envoyée par un nœud Diameter agissant en tant que client pour échanger des informations de comptabilisation avec un pair.

Outre les AVP listées ci-dessous, les messages Accounting-Request DEVRAIENT inclure des AVP de comptabilisation spécifiques au service.

Format du message (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

La commande Accounting-Answer (ACA), indiquée par le code 271 et le bit « R » effacé, sert à acquitter une Accounting-Request. Elle contient le même Session-Id que la demande correspondante.

Seul le serveur Diameter cible, dit serveur Diameter d'origine (home), DEVRAIT répondre par une Accounting-Answer.

Outre les AVP listées ci-dessous, les messages Accounting-Answer DEVRAIENT inclure des AVP de comptabilisation spécifiques au service.

Format du message (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 de comptabilisation (Accounting AVPs)

Cette section décrit les AVP relatives aux informations d'utilisation comptabilisée pour une session donnée.

9.8.1. Accounting-Record-Type AVP

L'AVP Accounting-Record-Type (code AVP 480) est de type Enumerated et indique le type d'enregistrement envoyé. Les valeurs définies actuellement sont :

EVENT_RECORD 1

Un enregistrement d'événement indique qu'un événement ponctuel s'est produit (début et fin simultanés). Il contient toute l'information pertinente sur le service et constitue le seul enregistrement du service.

START_RECORD 2

Les enregistrements Start, Interim et Stop indiquent qu'un service de durée mesurable a été fourni. Un enregistrement Start initie une session de comptabilisation et contient les informations pertinentes au démarrage.

INTERIM_RECORD 3

Un enregistrement intermédiaire contient des informations cumulatives pour une session existante. Les enregistrements intermédiaires DEVRAIENT être envoyés à chaque ré-authentification ou ré-autorisation. Des déclencheurs supplémentaires PEUVENT être définis par des applications Diameter spécifiques. Le choix d'utiliser INTERIM_RECORD est guidé par l'AVP Acct-Interim-Interval.

STOP_RECORD 4

Un enregistrement Stop termine la session de comptabilisation et contient les informations cumulatives pertinentes.

9.8.2. Acct-Interim-Interval AVP

L'AVP Acct-Interim-Interval (code 85) est de type Unsigned32 et est envoyée par le serveur d'autorisation d'origine Diameter au client. Le client s'en sert pour décider comment et quand produire les enregistrements. Selon la valeur, une session peut donner lieu à un, deux ou 2+N enregistrements, selon les besoins de l'organisation d'origine. Le comportement suivant est imposé par la présence de cette AVP :

L'omission de l'AVP ou une valeur 0 signifie que EVENT_RECORD, START_RECORD et STOP_RECORD sont produits selon le cas.
Une valeur non nulle signifie que des INTERIM_RECORD DOIVENT être produits entre START_RECORD et STOP_RECORD. Le champ Value est l'intervalle nominal en secondes entre ces enregistrements. Le nœud client DOIT produire le premier INTERIM_RECORD approximativement lorsque cet intervalle s'est écoulé depuis le START_RECORD, puis les suivants à chaque intervalle, jusqu'à la fin de session et l'envoi du STOP_RECORD.

Le client DOIT randomiser les instants de production des enregistrements intermédiaires afin d'éviter d'importantes rafales de messages, entre enregistrements ou autour d'un instant commun de démarrage de service.

9.8.3. Accounting-Record-Number AVP

L'AVP Accounting-Record-Number (code 485) est de type Unsigned32 et identifie l'enregistrement au sein d'une session. Comme les Session-Id sont globalement uniques, la combinaison Session-Id et Accounting-Record-Number l'est aussi et permet d'associer enregistrements et accusés. Une méthode simple consiste à utiliser 0 pour EVENT_RECORD et START_RECORD, 1 pour le premier INTERIM_RECORD, 2 pour le second, etc., jusqu'à STOP_RECORD égal au dernier INTERIM_RECORD plus un.

9.8.4. Acct-Session-Id AVP

L'AVP Acct-Session-Id (code 44) est de type OctetString et n'est utilisée que lors d'une traduction RADIUS/Diameter. Elle contient le contenu de l'attribut RADIUS Acct-Session-Id.

9.8.5. Acct-Multi-Session-Id AVP

L'AVP Acct-Multi-Session-Id (code 50) est de type UTF8String, selon le format de la Section 8.8. Elle relie plusieurs sessions de comptabilisation apparentées, chacune ayant un Session-Id unique mais le même Acct-Multi-Session-Id. Elle PEUT être renvoyée par le serveur dans une réponse d'autorisation et DOIT figurer dans tous les messages de comptabilisation de la session.

9.8.6. Accounting-Sub-Session-Id AVP

L'AVP Accounting-Sub-Session-Id (code 287) est de type Unsigned64 et contient l'identifiant de sous-session. La combinaison avec le Session-Id DOIT être unique par sous-session, et la valeur DOIT augmenter de un de manière monotone pour chaque nouvelle sous-session. L'absence de cette AVP signifie qu'aucune sous-session n'est utilisée, sauf pour une Accounting-Request dont Accounting-Record-Type vaut STOP_RECORD. Un STOP_RECORD sans Accounting-Sub-Session-Id indique la terminaison de toutes les sous-sessions pour le Session-Id donné.

9.8.7. Accounting-Realtime-Required AVP

L'AVP Accounting-Realtime-Required (code 483) est de type Enumerated et est envoyée par le serveur d'autorisation d'origine au client, ou dans l'Accounting-Answer par le serveur de comptabilisation. Le client s'en sert pour décider que faire si l'envoi des enregistrements est temporairement empêché, par exemple par un problème réseau.

DELIVER_AND_GRANT 1

La valeur DELIVER_AND_GRANT signifie que le service NE DOIT être accordé que tant qu'il existe une connexion vers un serveur de comptabilisation. L'ensemble des serveurs de secours est traité comme un seul serveur à cet égard. Le basculement du flux d'enregistrements vers un serveur de secours n'est pas un motif d'interruption du service.

GRANT_AND_STORE 2

La valeur GRANT_AND_STORE signifie que le service DEVRAIT être accordé s'il y a connexion, ou tant que les enregistrements peuvent encore être stockés comme décrit en Section 9.4.

C'est le comportement par défaut si l'AVP est absente de la réponse du serveur d'autorisation.

GRANT_AND_LOSE 3

La valeur GRANT_AND_LOSE signifie que le service DEVRAIT être accordé même si les enregistrements ne peuvent être ni livrés ni stockés.