Network Working Group A

Conventions textuelles pour les types de données
à haute capacité supplémentaires

Le présent document spécifie un protocole Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et des suggestions pour son amélioration. Prière de se reporter à l’édition actuelle du STD 1 "Normes des protocoles officiels de l’Internet" pour connaître l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Le présent mémoire spécifie de nouvelles conventions textuelles (TC, Textual Convention) pour des types de données supplémentaires à haute capacité, destinés aux mises en œuvre de SNMP qui prennent déjà en charge le type de données Counter64. Les définitions contenues dans le présent document représentent une solution à court terme qui pourrait être déconseillée à l’avenir.

Table des Matières

1. Cadre de gestion SNMP 1

2. Généralités 2

2.1 Objectifs de court et de long terme 2

2.2 Limitations de l’approche de la convention textuelle 2

3. Nouvelles conventions textuelles 3

3.1 CounterBasedGauge64 3

3.2 ZeroBasedCounter64 3

4. Définitions 3

5. Propriété intellectuelle 4

6. Références 5

7. Considérations pour la sécurité 6

8. Adresse des auteurs 6

9. Déclaration complète de droits de reproduction 6

o Des mécanismes de description et de désignation des objets et événements pour les besoins de la gestion. La première version de cette structure des informations de gestion (SMI) est appelée SMIv1 et est décrite dans le STD 16, [RFC1155], [RFC1212] et [RFC1215]. La seconde version, appelée SMIv2, est décrite dans le STD 58, [RFC2578], [RFC2579] et [RFC2580].

o Des protocoles de message pour transférer les informations de gestion. La première version du protocole de message SNMP est appelée SNMPv1 et est décrite dans le STD 15, [RFC1157]. Une seconde version du protocole de message SNMP, qui n’est pas un protocole en cours de normalisation de l’Internet, est appelée SNMPv2c et est décrite dans la [RFC1901] et la [RFC1906]. La troisième version du protocole de message est appelée SNMPv3 et est décrite dans la [RFC1906], la [RFC2572] et la [RFC2574].

o Les opérations du protocole pour accéder aux informations de gestion. Le premier ensemble d’opérations de protocole et des formats de PDU associés est décrit dans le STD 15, [RFC1157]. Un second ensemble d’opérations du protocole et des formats de PDU associés est décrit dans la [RFC1905].

o Un ensemble d’applications fondamentales décrites dans la [RFC2573] et le mécanisme de contrôle d’accès fondé sur la vue décrit dans la [RFC2575].

Une introduction plus détaillée au cadre de gestion SNMP actuel se trouve dans la [RFC2570].

On accède aux objets gérés via une mémorisation virtuelle des informations, appelée la base de données d’informations de gestion (MIB, Management Information Base). Les objets dans la MIB sont définis en utilisant les mécanismes définis dans la SMI.

Le présent mémoire spécifie un module de MIB qui est conforme à SMIv2. Les conventions textuelles définies dans ce module de MIB ne peuvent pas être traduits dans la SMIv1 car le type Counter64 n’existe pas dans SMIv1.

La structure des informations de gestion [RFC2578] ne s’adresse pas explicitement à la question de comment représenter des objets entiers autrement que comme des compteurs qui exigeraient jusqu’à 64 bits pour fournir la gamme et la précision nécessaire. Des MIB en cours qui sont destinées à suivre le processus de normalisation, ont besoin de tels types de données. Le présent mémoire spécifie une solution à court terme, en utilisant des conventions textuelles, pour satisfaire ces besoins.

Il y a un besoin immédiat de fournir un type de données Gauge64, de sémantique similaire à celle du type de données Gauge32, afin de prendre en charge des représentations de données courantes telles que :

- une photographie d’un Counter64 à un moment donné, par exemple, une mémoire tampon d’anneau d’historique,

Il y a aussi un besoin immédiat d’un type de compteur de 64 bits fondé sur zéro, de sémantique similaire à celle de la TC ZeroBasedCounter32 défini dans la MIB RMON-2 [RFC2021].

Ces deux conventions textuelles devraient utiliser un type de base de Gauge64 ou Unsigned64, mais un tel type de base n’est pas disponible. Jusqu’à ce qu’un tel type de base soit défini et mis en œuvre, ces conventions textuelles temporaires (qui utilisent un type de base de Counter64) seront utilisées dans les MIB qui exigent des types de données non signées de 64 bits.

Afin d’être rétro compatible avec les mises en œuvre existantes de Counter64, le codage ASN.1 des types de données de 64 bits non signées doit être identique au codage des objets Counter64, c’est-à-dire, identifié par l’étiquette ASN.1 [APPLICATION 6].

Noter que les conventions textuelles définies dans le présent document représentent une solution limitée et à court terme de ce problème. Ces conventions textuelles pourraient être déconseillées lorsque une solution à long terme sera définie et mise en œuvre pour les remplacer. Un objet de MIB qui utilise une de ces conventions textuelles pourrait aussi être éventuellement déconseillé.

Les nouveaux types de données non signées avec des conventions textuelles fondées sur l’étiquette Counter64, au lieu d’une nouvelle étiquette ASN.1 (ou d’une autre déjà existante) ont certaines limitations :

- le MAX-ACCESS de la TC doit être en lecture seule, parce que le MAX-ACCESS du type Counter64 sous-jacent est en lecture seule ;

- aucune sous-gamme ne peut être spécifiée sur les types déduits de la TC, parce que les sous-gammes ne sont pas permise sur les objets Counter64 ;

- aucune clause DEFVAL ne peut être spécifiée pour les types déduits de la TC, parce que les DEFVAL ne sont pas permises sur les objets Counter64 ;

- les types déduits de la TC ne peuvent pas être utilisés dans une clause INDEX, parce qu’il n’y a pas de transposition de clause INDEX définie pour les objets de type Counter64.

Les conventions textuelles suivantes sont définies pour prendre en charge les types de données de 64 bits non signées.

Cette convention textuelle définit un gabarit de 64 bits, mais avec la syntaxe de Counter64, car aucun type de base Gauge64 ou Unsigned64 n’est disponible dans SMIv2.

Cette TC est utilisée pour mémoriser la différence entre deux valeurs de Counter64, ou mémoriser simplement une photographie d’une valeur de Counter64 à un certain moment dans le temps.

Cette convention textuelle définit un compteur de 64 bits avec une valeur initiale de zéro, au lieu d’une valeur initiale arbitraire.

Cette TC est utilisée pour des objets compteurs dans des tableaux qui sont instanciés par l’action d’une application de gestion.

"Module de MIB contenant des conventions textuelles pour types de données à hautes capacités. Ce module s’adresse à un besoin immédiat de types de données non directement pris en charge dans SMIv2. Cette solution à court terme est destinée à être déconseillée lorsque une solution à long terme sera mise en œuvre".

"Version initiale du module de MIB de nombre à grande capacité, publiée comme RFC 2856".

"Le type CounterBasedGauge64 représente un entier non négatif, qui peut augmenter ou diminuer, mais ne devra jamais excéder une valeur, ni tomber en dessous d’une valeur minimum. La valeur maximum ne peut pas être supérieure à 2^64-1 (18 446 744 073 709 551 615 en décimal) et la valeur minimum ne peut pas être inférieure à 0. La valeur d’un CounterBasedGauge64 a sa valeur maximum chaque fois que les informations modélisées sont supérieures ou égales à leur valeur maximum, et a sa valeur minimum chaque fois que les informations modélisées sont inférieures ou égales à leur valeur minimum. Si les informations modélisées diminuent ensuite en dessous (augmentent au dessus) de la valeur maximum (minimum) le CounterBasedGauge64 diminue (augmente) aussi.

Noter que cette TC n’est pas strictement prise en charge dans SMIv2, parce que la sémantique de 'augmente toujours' et de 'retour de compteur' associée au type de base Counter64 n’est pas préservée. Il est possible que les applications de gestion qui s’appuient seulement sur l’étiquette ASN.1 (Counter64) pour déterminer la sémantique d’un objet fassent fonctionner à tord sur les objets de ce type comme elles l’auraient fait pour des objets Counter64.

Cette convention textuelle représente une solution limitée et à court terme, et peut être déconseillée lorsque une solution a long terme sera définie et mise en œuvre pour la remplacer".

"Cette TC décrit un objet qui compte des événements avec la sémantique suivante : les objets de ce type seront réglés à zéro(0) à la création et vont ensuite compter les événements appropriés, revenant à zéro(0) lorsque la valeur 2^64 est atteinte.

Pourvu qu’une application découvre le nouvel objet dans le temps minimum pour revenir à zéro, elle peut utiliser la valeur initiale comme une différence depuis la dernière fois qu’elle a interrogé le tableau dont fait partie cet objet. Il est important pour une station de gestion de connaître ce temps minimum et le temps réel entre les interrogations, et d’éliminer les données si le temps réel est trop long ou si un temps minimum n’est pas défini.

Normalement, cette TC est utilisée dans des tableaux où l’espace INDEX change constamment et/ou le mécanisme TimeFilter est utilisé.

Noter que cette convention textuelle ne conserve pas toute la sémantique du type de base Counter64. Précisément, un Counter64 a une valeur initiale arbitraire, mais les objets définis avec cette TC sont obligés de commencer à la valeur zéro. Ce comportement ne devrait vraisemblablement pas avoir d’effet contraire sur les applications de gestion qui s’attendent à la sémantique de Counter64.

Cette convention textuelle représente une solution limitée et de court terme, et pourrait être déconseillée lorsque une solution à long terme sera définie et mise en œuvre pour la remplacer.

L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourrait être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP 78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr.

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf-ipr@ietf.org.

[RFC1157] J. Case, M. Fedor, M. Schoffstall et J. Davin, "Protocole simple de gestion de réseau", STD 15, mai 1990. (Historique)

[RFC1215] M. Rose, "Convention pour la définition de filtres à utiliser avec le SNMP", mars 1991. (Info)

[RFC1901] J. Case, K. McCloghrie, M. Rose, S. Waldbusser "Introduction à SNMPv2 fondé sur la communauté", janvier 1996. (Historique)

[RFC1905] J. Case, K. McCloghrie, M. Rose, S. Waldbusser "Opérations de protocole pour la version 2 du protocole simple de gestion de réseau (SNMPv2)", janvier 1996. (Obsolète, voir RFC3416) (D.S.)

[RFC1906] J. Case, K. McCloghrie, M. Rose, S. Waldbusser "Transpositions de transport pour la version 2 du protocole simple de gestion de réseau (SNMPv2)", janvier 1996. (Obsolète, voir RFC3417) (D.S.)

[RFC2021] S. Waldbusser, "Base de données d'informations de gestion de surveillance de réseau à distance version 2 avec SMIv2", janvier 1997. (Obsolète, voir RFC4502) (P.S.)

[RFC2570] J. Case, R. Mundy, D. Partain, B. Stewart, "Introduction à la version 3 du cadre de gestion de réseau de l'Internet", avril 1999. (Obsolète, voir RFC3410) (Information)

[RFC2571] B. Wijnen, D. Harrington, R. Presuhn, "Architecture pour la description des cadres de gestion SNMP", avril 1999. (Obsolète, voir RFC3411) (D.S.)

[RFC2572] J. Case, D. Harrington, R. Presuhn, B. Wijnen, "Traitement et répartition de message pour le protocole simple de gestion de réseau (SNMP)", avril 1999. (Obsolète, voir RFC3412) (D.S.)

[RFC2573] D. Levi, P. Meyer, B. Stewart, "Applications SNMP", avril 1999. (Obsolète, voir RFC3413) (D.S.)

[RFC2574] U. Blumenthal, B. Wijnen, "Modèle de sécurité fondé sur l'utilisateur (USM) pour la version 3 du protocole simple de gestion de réseau (SNMPv3)", avril 1999. (Obsolète, voir RFC3414) (D.S.)

[RFC2575] B. Wijnen, R. Presuhn, K. McCloghrie, "Modèle de contrôle d'accès fondé sur la vue (VACM) pour le protocole simple de gestion de réseau (SNMP)", avril 1999. (Obsolète, voir RFC3415) (D.S.)

Le présent module ne définit aucun objet de gestion. Il définit plutôt un ensemble de conventions textuelles qui peuvent être utilisées par d’autres modules de MIB pour définir des objets de gestion.

Des considérations significatives pour la sécurité ne peuvent être écrites que dans les modules qui définissent des objets de gestion.

Ce document et les traductions de celui-ci peuvent être copiés et diffusés, et les travaux dérivés qui commentent ou expliquent autrement ou aident à sa mise en œuvre peuvent être préparés, copiés, publiés et distribués, partiellement ou en totalité, sans restriction d'aucune sorte, à condition que l'avis de copyright ci-dessus et ce paragraphe soit inclus sur toutes ces copies et œuvres dérivées. Toutefois, ce document lui-même ne peut être modifié en aucune façon, par exemple en supprimant le droit d'auteur ou les références à l'Internet Society ou d'autres organisations Internet, sauf si c'est nécessaire à l'élaboration des normes Internet, auquel cas les procédures pour les droits de reproduction définis dans les processus des normes pour l'Internet doivent être suivies, ou si nécessaire pour le traduire dans des langues autres que l'anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Société Internet, ses successeurs ou ayants droit.

Ce document et les renseignements qu'il contient sont fournis "TELS QUELS" et l'INTERNET SOCIETY et l'INTERNET ENGINEERING TASK FORCE déclinent toute garantie, expresse ou implicite, y compris mais sans s'y limiter, toute garantie que l'utilisation de l'information ici présente n'enfreindra aucun droit ou aucune garantie implicite de commercialisation ou d'adaptation a un objet particulier.

Le financement de la fonction d’éditeur des RFC est actuellement fourni par la Internet Society.

Groupe de travail Réseau	A. Bierman & K. McCloghrie, Cisco Systems, Inc.
Request for Comments : 2856	R. Presuhn, BMC Software, Inc.
Catégorie : En cours de normalisation	juin 2000
Traduction Claude Brière de L’Isle

Andy Bierman	Keith McCloghrie	Randy Presuhn
Cisco Systems, Inc.	Cisco Systems, Inc.	BMC Software, Inc.
170 West Tasman Drive	170 West Tasman Drive	Office 1-3141
San Jose, CA 95134 USA	San Jose, CA 95134 USA	2141 North First Street
téléphone : +1 408-527-3711	téléphone : +1 408-526-5260	San Jose, California 95131 USA
mél : abierman@cisco.com	mél: kzm@cisco.com	téléphone : +1 408 546-1006
		mél : rpresuhn@bmc.com