Structure et identification des informations de gestion pour les internets fondés sur TCP/IP

1. Statut du présent mémoire

La présente RFC est une nouvelle livraison de la RFC1065, avec un "Statut du présent mémoire" modifié, plus quelques corrections typographiques mineures. Le contenu technique du document est inchangé par rapport à la RFC1065.

Le présent mémoire fournit les définitions communes pour la structure et l’identification des informations de gestion pour les internets fondés sur TCP/IP. En particulier, conjointement avec les mémoires associés qui décrivent la base d’informations de gestion ainsi que le protocole de gestion de réseau, ces documents fournissent une architecture et un système simple et fonctionnel pour la gestion des internets fondés sur TCP/IP et en particulier, l’Internet.

Le présent mémoire spécifie un protocole standard pour la communauté de l’Internet. Son statut est "Recommandé". Les mises en œuvre TCP/IP dans l’Internet qui sont gérables par le réseau sont invitées à adopter et mettre en œuvre la présente spécification.

Le Bureau des activités de l’Internet recommande que toutes les mises en œuvre IP et TCP soient gérables par le réseau. Cela implique la mise en œuvre de la MIB Internet (RFC1156) et d’au moins un des deux protocoles recommandés de gestion SNMP (RFC1157) ou CMOT (RFC1095). Il devrait être noté que pour l’instant , SNMP est une norme de l’Internet à part entière et que CMOT est un projet de norme. Voir aussi dans les RFC des exigences pour les hôtes et les passerelles des informations plus spécifiques sur l’applicabilité de cette norme.

Prière de se référer à la plus récente édition de la RFC "Normes officielles des protocoles de l’IAB" pour les informations en cours sur l’état et le statut des normes de protocole de l’Internet.

La distribution du présent mémoire n’est soumise à aucune restriction.

2. Introduction

Le présent mémoire décrit les structures communes et le schéma d’identification pour la définition des informations de gestion utilisées pour la gestion des internets fondés sur TCP/IP. Il comporte des descriptions d’un modèle d’information d’objet pour la gestion de réseau ainsi qu’un ensemble de types génériques utilisés pour décrire les informations de gestion. Les descriptions formelles de la structure sont données à l’aide de la notation de syntaxe abstraite n° 1 (ASN.1, Abstract Syntax Notation One) [1].

Le présent mémoire s’occupe largement des préoccupations organisationnelles et de politique administrative : il ne spécifie pas les objets qui sont gérés, ni les protocoles utilisés pour gérer ces objets. Ces questions sont traitées par deux documents associés : l’un qui décrit la base d’informations de gestion (MIB, Management Information Base) [2], et l’autre qui décrit le protocole simple de gestion de réseau (SNMP, Simple Network Management Protocol) [3].

Le présent mémoire se fonde en partie sur le travail du Groupe de travail de l’ingénierie de l’Internet (IETF), et en particulier sur la note de travail intitulée "Structure et identification des informations de gestion pour l’Internet" [4]. Le présent mémoire utilise une structure d’articulation dérivée de cette note, mais en diffère d’une façon très significative : cette note se focalise entièrement sur l’utilisateur de la gestion de réseau de style OSI. Comme telle, elle ne convient pas pour l’utilisation avec SNMP.

Le présent mémoire essaye d’atteindre deux objectifs : la simplicité et l’extensibilité. Tous deux sont motivés par un souci commun : bien que la gestion des internets fondés sur TCP/IP ait été un sujet d’étude depuis un certain temps, les auteurs n’ont pas le sentiment que sa compréhension en profondeur ait été achevée. Plus crûment, nous pensons que les expériences précédentes, bien qu’elles aient donné un aperçu de problèmes à la communauté, ne sont pas concluantes. En développant une SMI simple, on impose un nombre minimal de contraintes aux approches potentielles futures ; de plus, en développant une SMI extensible, on maximise les approches potentielles disponibles pour l’expérimentation.

On estime que le présent mémoire et ses deux compagnons se conforment aux lignes directrices établies par la RFC1052, "Recommandations de l’IAB pour le développement des normes de gestion de réseau de l’Internet" [5] et la RFC 1109, "Rapport du second groupe ad hoc de révision de la gestion de réseau" [6]. En particulier, on estime que le présent mémoire, conjointement avec le mémoire qui décrit la base d’informations de gestion, fournit une base solide pour la gestion de réseau de l’Internet.

3. Structure et identification des informations de gestion

On accède aux objets gérés via une base de données d’informations virtuelle, appelée base d’informations de gestion ou MIB. Les objets dans la MIB sont définis à l’aide de la notation de syntaxe abstraite n° 1 (ASN.1, Abstract Syntax Notation One) [1].

Chaque type d’objet a un nom, une syntaxe, et un codage. Le nom est représenté de façon univoque comme un IDENTIFIANT D’OBJET. Un IDENTIFIANT D’OBJET est un nom alloué de façon administrative. Les politiques administrative utilisées pour allouer les noms sont exposées plus loin.

La syntaxe pour un objet type définit la structure abstraite des données correspondant à cet objet type. Par exemple, la structure d’un objet type donné pourrait être un ENTIER ou une CHAINE D’OCTETS. Bien qu’en général, on doive permettre que toute construction ASN.1 soit disponible pour être utilisée à la définition de la syntaxe d’un objet type, le présent mémoire restreint délibérément les constructions ASN.1 qui peuvent être utilisées. Ces restrictions ne sont faites que par souci de simplicité.

Le codage d’un objet type est simplement la façon dont les instances de cet objet type sont représentées en utilisant la syntaxe type de l’objet. Implicitement liée à cette notion de la syntaxe et du codage d’un objet est la façon dont l’objet est représenté lorsqu’il est transmis sur le réseau. Le présent mémoire spécifie l’utilisation des règles de codage de base de l’ASN.1 [7].

Il sort du domaine d’application du présent mémoire de définir la MIB utilisée pour la gestion de réseau ou le protocole de gestion de réseau. Comme mentionné plus haut, ces tâches appartiennent aux documents associés. Le présent mémoire essaye de minimiser les restrictions relevant de ces documents compagnons de façon à en maximiser la généralité. Cependant, dans certains cas, des restrictions ont été faites (par exemple, la syntaxe qui peut être utilisée lors de la définition des types d’objet dans la MIB) afin d’encourager un style particulier de gestion. Des éditions futures du présent mémoire pourront lever ces restrictions.

3.1 Noms

Les noms servent à identifier les objets gérés. Le présent mémoire spécifie les noms qui sont hiérarchiques par nature. Le concept de IDENTIFIANT D’OBJET sert à modéliser cette notion. Un IDENTIFIANT D’OBJET peut être utilisé pour des besoins autres que de nommer les types d’objet géré ; par exemple, chaque norme internationale a un IDENTIFIANT D’OBJET qui lui est alloué pour les besoins de l’identification. En bref, les IDENTIFIANT D’OBJET sont un moyen pour identifier un objet, indépendamment de la sémantique associée à l’objet (par exemple, un objet du réseau, un document de normalisation, etc.)

Un IDENTIFIANT D’OBJET est une séquence d’entiers qui traverse un arbre global. L’arbre comporte une racine connectée à un certain nombre de nœud étiquetés via des branches. Chaque nœud peut à son tour avoir des enfants à lui qui sont étiquetés. Dans ce cas, on peut appeler le nœud un sous-arbre. Ce processus peut continuer jusqu’à un niveau de profondeur arbitraire. Centrale pour la notion de IDENTIFIANT D’OBJET est la compréhension que le contrôle administratif de la signification attribuée aux nœuds peut être délégué quand on traverse l’arbre. Une étiquette est un appariement d’une brève description textuelle et d’un entier.

Le nœud racine lui-même n’est pas étiqueté, mais il a au moins trois enfants directement sous lui : un nœud est administré par l’Organisation mondiale de normalisation (ISO), avec l’étiquette iso(1) , un autre est administré par le Comité consultatif international du télégraphe et du téléphone, avec l’étiquette ccitt(0) ; et le troisième est administré conjointement par l’ISO et le CCITT, joint-iso-ccitt(2).

Sous le nœud iso(1), l’ISO a désigné un sous-arbre à l’usage des autres organisations (inter)nationales, org(3). Des nœuds fils présents, deux ont été alloués à l’Institut national américain pour les normes et les technologies (NIST). Un de ces sous-arbres a été transféré par le NIST au Département américain de la défense, dod(6).

Au moment de la rédaction de ce texte, le DoD n’a pas indiqué comment il gère son sous-arbre d’IDENTIFIANT D’OBJET. Le présent mémoire suppose que le DoD allouera un nœud à la communauté Internet, pour qu’il soit administré par le bureau des activités de l’Internet (IAB, Internet Activities Board) comme suit :

IDENTIFIANT D’OBJET internet ::= { iso org(3) dod(6) 1 }

C’est à dire que le sous-arbre Internet des IDENTIFIANT D’OBJET commence par le préfixe : 1.3.6.1.

Le présent mémoire, en tant que norme approuvée par l’IAB, spécifie maintenant la politique selon laquelle est administré ce sous-arbre des IDENTIFIANT D’OBJET. Au départ, quatre nœuds sont présents :

directory	IDENTIFIANT D’OBJET	::= { internet 1 }
mgmt	IDENTIFIANT D’OBJET	::= { internet 2 }
experimental	IDENTIFIANT D’OBJET	::= { internet 3 }
private	IDENTIFIANT D’OBJET	::= { internet 4 }

3.1.1 Directory

Le sous-arbre directory(1) (répertoire) est réservé à une utilisation par un futur document qui expose comment le répertoire OSI pourra être utilisé dans l’Internet.

3.1.2 Mgmt

Le sous-arbre mgmt(2) (gestion) est utilisé pour identifier les objets qui sont définis dans les documents approuvés par l’IAB. L’administration du sous-arbre mgmt(2) est déléguée par l’IAB à l’Autorité d’allocation des numéros de l’Internet (IANA, Internet Assigned Numbers Authority) pour l’Internet. Comme les RFC qui définissent de nouvelles versions de la base d’information de gestion standard de l’Internet sont approuvées , il leur est alloué un IDENTIFIANT D’OBJET par l’IANA pour identifier les objets définis par le présent mémoire.

Par exemple, la RFC qui définit la MIB standard Internet initial se verrait allouer le numéro de document de gestion 1. Cette RFC utiliserait l’IDENTIFIANT D’OBJET { mgmt 1 } ou 1.3.6.1.2.1 pour définir la MIB Internet standard.

La génération de nouvelles versions de la MIB Internet standard est un processus rigoureux. La Section 5 du présent mémoire décrit les règles utilisées pour la définition d’une nouvelle version.

3.1.3 Experimental

Le sous-arbre experimental(3) est utilisé pour identifier les objets utilisés dans les expérimentations de l’Internet. L’administration du sous-arbre experimental(3) est déléguée par l’IAB à l’IANA.

Par exemple, un expérimentateur pourrait recevoir le numéro 17, et aurait l’IDENTIFIANT D’OBJET { experimental 17 } ou 1.3.6.1.3.17 disponible pour son usage.

Au titre du processus d’allocation, l’autorité d’allocation des numéros de l’Internet peut formuler des exigences sur la façon d’utiliser ce sous-arbre.

3.1.4 Private

Le sous-arbre private(4) est utilisé pour identifier des objets définis unilatéralement. L’administration du sous-arbre private(4) est délégué par l’IAB à l’Autorité d’allocation des numéros de l’Internet pour l’Internet. Au départ, ce sous-arbre a au moins un fils :

IDENTIFIANT D’OBJET enterprises ::= { private 1 }

Le sous-arbre enterprises(1) est utilisé, entre autres choses, pour permettre aux entités qui fournissent des sous-systèmes de réseautage d’enregistrer les modèles de leurs produits.

À réception d’un sous-arbre, l’entreprise peut, par exemple, définir de nouveaux objets de MIB dans ce sous-arbre. De plus, il est vivement recommandé que l’entreprise enregistre aussi ses sous-systèmes de réseautage dans ce sous-arbre, afin de fournir un mécanisme non ambigu d’identification à utiliser dans les protocoles de gestion. Par exemple, si l’entreprise "Flintstones, Inc." produit des sous-systèmes de réseautage, elle peut alors demander un nœud dans le sous-arbre enterprises à l’IANA. Un tel nœud pourrait être numéroté : 1.3.6.1.4.1.42

L’entreprise "Flintstones, Inc." pourrait alors enregistrer son "Fred Router" sous le nom de : 1.3.6.1.4.1.42.1.1

3.2 Syntaxe

La syntaxe est utilisée pour définir la structure correspondant aux types d’objet. Les constructions ASN.1 sont utilisées pour définir cette structure, bien que toutes les possibilités de l’ASN.1 ne soient pas permises.

Le type ASN.1 ObjectSyntax définit les différentes syntaxes qui peuvent être utilisées dans la définition d’un type d’objet.

3.2.1 Types de primitive

Seuls les types de primitive ASN.1 INTEGER (ENTIER), OCTET STRING (CHAINE D’OCTET), OBJECT IDENTIFIER (IDENTIFIANT D’OBJET), et NULL (NUL) sont permises. Elles sont parfois désignées comme des types non agrégés.

3.2.1.1 Lignes directrices pour les ENTIER énumérés

Si un ENTIER énuméré figure sur la liste comme type d’objet, il ne doit alors pas y avoir dans la liste de l’énumération de nombre désigné avec la valeur 0. L’utilisation de cette valeur est interdite.

3.2.2 Types constructeurs

Le type ASN.1 constructeur SEQUENCE est permis, pourvu qu’il soit utilisé pour générer des listes ou des tableaux.

Pour les listes, la syntaxe prend la forme :

SEQUENCE { <type1>, ..., <typeN> }

où chaque <type> se résout en un des types de primitive ASN.1 dont la liste figure ci-dessus. De plus, ces types ASN.1 sont toujours présents (les clauses DEFAUT et OPTIONNEL n’apparaissent pas dans la définition de SEQUENCE).

Pour les tableaux, la syntaxe prend la forme :

SEQUENCE DE <entrée>

où <entrée> se résout en un constructeur de liste.

Les listes et les tableaux sont parfois désignés sous le nom de types agrégés.

3.2.3 Types définis

De plus, peuvent être définis de nouveaux types pour toute une application, pour autant qu’ils se résolvent en un type de primitive implicitement défini en ASN.1, list, table, ou quelque autre type pour toute une application. Au départ, peu de types sont définis pour toute une application. Des mémoires futurs en définiront sans doute d’autres quand un consensus sera obtenu.

3.2.3.1 NetworkAddress

Ce CHOIX représente une adresse parmi plusieurs familles de protocoles possibles. Actuellement, une seule famille de protocoles, la famille Internet, est présente dans ce CHOIX.

3.2.3.2 IpAddress

Ce type valable pour toute une application représente une adresse internet de 32 bits. Il est représenté par une CHAINE D’OCTETS de longueur 4, dans l’ordre des octets du réseau.

Lorsque ce type ASN.1 est codé en utilisant les règles de codage de base ASN.1, seule la forme de codage en primitive doit être utilisée.

3.2.3.3 Counter

Ce type valable pour toute une application représente un entier non négatif qui augment de façon monotone jusqu’à atteindre une valeur maximum, il revient alors à zéro et recommence alors à croître. Le présent mémoire spécifie une valeur maximum de 2³²-1 (4 294 967 295 en décimal) pour les compteurs.

3.2.3.4 Gauge

Ce type valable pour toute une application représente un entier non négatif, qui peut croître ou décroître, mais qui se verrouille sur une valeur maximum. Le présent mémoire spécifie une valeur maximum de 2³²-1 (4 294 967 295 en décimal) pour les indicateurs.

3.2.3.5 TimeTicks

Ce type valable pour toute une application représente un entier non négatif qui compte le temps en centièmes de secondes à partir d’un instant donné. Lorsque des types d’objet définis dans la MIB utilisent ce type ASN.1, la description du type d’objet identifie l’instant de référence.

3.2.3.6 Opaque

Ce type valable pour toute une application prend en charge la capacité à passer une syntaxe ASN.1 arbitraire. Une valeur est codée en utilisant les règles de codage de base ASN.1 dans une chaîne d’octets. Ceci est ensuite codé comme CHAINE D’OCTETS, ce qui a pour effet un "double enveloppement" de la valeur ASN.1 originale.

Noter qu’une mise en œuvre conforme a seulement besoin d’être capable d’accepter et reconnaître les données en codage opaque. Elle n’a pas besoin d’être capable de désenvelopper les données pour interpréter leur contenu.

Noter de plus qu’en utilisant le type ASN.1 EXTERNAL, les codages autres que ASN.1 peuvent être utilisés dans des données à codage opaque.

3.3 Codages

Une fois qu’une instance d’un type d’objet a été identifiée, sa valeur peut être transmise en appliquant les règles de codage de base de l’ASN.1 à la syntaxe du type d’objet.

4. Objets gérés

Bien que ce ne soit pas l’objet du présent mémoire de définir les objets qui sont dans la MIB, le présent mémoire spécifie un format à utiliser par les normes qui définissent ces objets.

Une définition de type d’objet comporte cinq champs :

OBJET : Nom textuel, appelé le DESCRIPTEUR D’OBJET, pour le type d’objet, avec son IDENTIFIANT D’OBJET correspondant.

Syntaxe : La syntaxe abstraite pour le type d’objet. Elle doit se résoudre en une instance du type ASN.1 ObjectSyntax (défini plus loin).

Définition : Description textuelle de la sémantique du type d’objet. Les mises en œuvre devraient s’assurer que leur instance de l’objet satisfait à cette définition car cette MIB est destinée à être utilisée dans des environnements multi fabricants. À ce titre, il est vital que les objets aient une signification cohérente à travers toutes les machines.

Accès : Lecture-seule, lecture-écriture, écriture-seule, ou non-accessible.

Statut : Obligatoire, facultatif, ou obsolète.

De futures normes pourront aussi spécifier d’autres champs pour les objets qu’elles définiront.

4.1 Lignes directrices pour les noms d’objet

Aucun type d’objet de MIB de l’Internet standard ne doit utiliser de sous identifiant de 0 dans son nom. Cette valeur est réservée pour utilisation avec des extensions futures.

Chaque DESCRIPTEUR D’OBJET correspondant à un type d’objet dans la MIB standard internet doit être une chaîne imprimable unique, mais mnémonique. Ceci va en faveur d’un langage commun pour les hommes, à utiliser lors de discussions sur la MIB et facilite aussi les transpositions simples de tableaux pour les interfaces d’utilisateur.

4.2 Types et instances d’objet

Un type d’objet est une définition d’une sorte d’objet géré ; elle est déclarative par nature. À l’opposé, une instance d’objet est une instanciation d’un type d’objet qui a été liée à une valeur. Par exemple, la notion d’entrée dans un tableau d’acheminement pourrait être définie dans la MIB. Une telle notion correspond à un type d’objet type ; les entrées individuelles dans un tableau d’acheminement particulier qui existe à un instant donné sont des instances d’objet de ce type d’objet.

Une collection des types d’objets est définie dans la MIB. Chacun de ces types sujets est désigné de façon univoque par son IDENTIFIANT D’OBJET et il a aussi un nom textuel, qui est son DESCRIPTEUR D’OBJET. Les moyens par lesquels les instances d’objet sont référencées ne sont pas définis dans la MIB. La référence aux instances d’objets est réalisée par un mécanisme spécifique du protocole : il est de la responsabilité de chaque protocole de gestion qui adhère à la SMI de définir ce mécanisme.

Un type d’objet peut être défini dans la MIB de telle sorte qu’une instance de ce type d’objet représente une agrégation des informations aussi représentées par des instances d’un certain nombre de types d’objets "subordonnés". Par exemple, supposons que les types d’objet suivants soient définis dans la MIB :

OBJET : atIndex { atEntry 1 }

Syntaxe : ENTIER

Définition : Numéro de l’interface pour l’adresse physique.

Accès : lecture-écriture.

Statut : obligatoire.

OBJET : atPhysAddress { atEntry 2 }

Syntaxe : CHAINE D’OCTETS

Définition : L’adresse physique dépendante du support.

Accès : lecture-écriture.

Statut: obligatoire.

OBJET : atNetAddress { atEntry 3 }

Syntaxe : NetworkAddress

Définition : L’adresse réseau correspondant à l’adresse physique dépendant du support.

Accès : lecture-écriture.

Statut : obligatoire.

Puis, un quatrième type d’objet pourrait aussi être défini dans la MIB :

OBJET : atEntry { auTableau 1 }

Syntaxe :

AtEntry ::= SEQUENCE {

atIndex

ENTIER,

atPhysAddress

CHAINE D’OCTETS,

atNetAddress

NetworkAddress

}

Définition : Une entrée dans le tableau de traduction d’adresses.

Accès : lecture-écriture.

Statut : obligatoire.

Chaque instance de ce type d’objet comporte les informations représentées par les instances des trois types d’objet précédents. Un type d’objet défini de cette façon est appelé une liste.

De même, les tableaux peuvent être formés par l’agrégation de types de listes. Par exemple, un cinquième type d’objet pourrait aussi être défini dans la MIB :

OBJET : atTable { à 1 }

Syntaxe : SEQUENCE DE AtEntry

Définition : Le tableau de traduction d’adresses.

Accès : lecture-écriture.

Statut : obligatoire.

de telle sorte que chaque instance de l’objet atTable comporte les informations représentées par l’ensemble des types d’objet atEntry qui constituent collectivement une instance donnée d’objets atTable, c’est-à-dire, un tableau de traduction d’adresses donné.

Considérons comment on peut se référer à un simple objet au sein d’un tableau. En continuant avec l’exemple précédent, on peut nommer le type d’objet { atPhysAddress } et spécifier, en utilisant un mécanisme spécifique du protocole, l’instance d’objet { atNetAddress } = { internet "10.0.0.52" }.

Cet appariement d’un type d’objet et d’instance d’objet se réfèrerait à toutes les instances de atPhysAddress qui font partie de toute entrée dans un tableau de traduction d’adresse pour laquelle la valeur associée de atNetAddress est { internet "10.0.0.52" }.

Pour poursuivre avec cet exemple, considérons comment on pourrait se référer à un objet agrégé (liste) au sein d’un tableau. Nommer le type d’objet { atEntry }et spécifier, à l’aide d’un mécanisme spécifique du protocole, l’instance d’objet { atNetAddress } = { internet "10.0.0.52" } se réfère à toutes les instances des entrées du tableau pour lesquelles la valeur associée atNetAddress est { internet "10.0.0.52" }.

Chaque protocole de gestion doit fournir un mécanisme d’accès aux types d’objet simples (non agrégés). Chaque protocole de gestion spécifie si il prend en charge ou non l’accès aux types d’objet agrégé. De plus, le protocole doit spécifier quelles instances sont "retournées" lorsque un appariement de type/instance d’objet se réfère à plus d’une instance d’un type.

Pour permettre la prise en charge d’une diversité de protocoles de gestion, toutes les informations par lesquelles les instances d’un type d’objet donné peuvent être utilement distinguées l’une de l’autre sont représentées par des instances des types d’objet définis dans le MIB.

4.3 Macros pour les objets gérés

Afin de faciliter l’utilisation des outils de traitement de la définition de la MIB, la macro OBJECT-TYPE peut être utilisée. Cette macro permet de représenter les aspects clés d’un type d’objet d’une façon formelle.

OBJECT-TYPE MACRO ::=

BEGIN

TYPE NOTATION ::= "SYNTAX" type (TYPE ObjectSyntax)

"ACCESS" Accès

"STATUS" Statut

VALUE NOTATION ::= valeur (VALUE ObjectName)

Accès ::= "lecture-seule" | "lecture-écriture"

| "écriture-seule"

| "non-accessible"

Statut ::= "obligatoire"

| "facultatif"

| "obsolète"

END

Étant donnés les types d’objet définis plus haut, on peut imaginer que les définitions suivantes sont présentes dans la MIB:

atIndex OBJECT-TYPE

SYNTAXE ENTIER

ACCÊS lecture-écriture

STATUT obligatoire

::= { atEntry 1 }

atPhysAddress OBJECT-TYPE

SYNTAXE CHAINE D’OCTETS

ACCÊS lecture-écriture

STATUT obligatoire

::= { atEntry 2 }

atNetAddress OBJECT-TYPE

SYNTAXE NetworkAddress

ACCÊS lecture-écrituree

STATUT obligatoire

::= { atEntry 3 }

atEntry OBJECT-TYPE

SYNTAXE AtEntry

ACCÊS lecture-écriture

STATUT obligatoire

::= { atTable 1 }

atTable OBJECT-TYPE

SYNTAXE SEQUENCE DE AtEntry

ACCÊS lecture-écriture

STATUT obligatoire

::= { at 1 }

AtEntry ::= SEQUENCE {

atIndex

ENTIER,

atPhysAddress

CHAINE D’OCTETS,

atNetAddress

NetworkAddress

}

Les cinq premières définitions décrivent des types d’objet, se rapportant, par exemple, au DESCRIPTEUR D’OBJET atIndex de l’IDENTIFIANT D’OBJET { atEntry 1 }. De plus, la syntaxe de cet objet est définie (ENTIER) conjointement avec l’accès permis (lecture-écriture) et le statut (obligatoire). La sixième définition décrit un type ASN.1 appelé AtEntry.

5. Extensions à la MIB

Chaque document de MIB standard de l’Internet rend obsolètes tous les document précédents de cette sorte. La portion d’un nom, appelée la queue, qui suit l’IDENTIFIANT D’OBJET { mgmt version-number } utilisée pour nommer les objets doit rester inchangée d’une version à l’autre. Les nouvelles versions peuvent :

(1) déclarer de vieux types d’objet obsolètes (si nécessaire), mais pas supprimer leurs noms ;

(2) augmenter la définition d’un type d’objet correspondant à une liste en ajoutant des types d’objet non agrégés aux types d’objet de la liste ; ou,

(3) définir des types d’objet entièrement nouveaux.

Les nouvelles versions ne peuvent pas :

(4) changer la sémantique d’un des objets précédemment définis sans changer le nom de cet objet.

Ces règles sont importantes parce qu’elles admettent une prise en charge plus facile de plusieurs versions de la MIB standard Internet. En particulier, la sémantique associée à la queue d’un nom reste constante à travers les différentes versions de la MIB. Parce que plusieurs versions de la MIB peuvent donc coïncider dans "l’espace de queue", les mises en œuvre qui acceptent plusieurs versions de la MIB peuvent en être grandement simplifiées.

Cependant, il en résulte qu’un agent de gestion peut retourner une instance correspondant à un surensemble du type d’objet attendu. Suivant le principe de robustesse, dans ce cas exceptionnel, un gestionnaire devrait ignorer toute information supplémentaire au delà de la définition du type d’objet attendu. Cependant, le principe de robustesse exige qu’on se comporte avec prudence par rapport aux actions de commande : si une instance n’a pas la même syntaxe que son type d’objet attendu, ces actions de commande doivent alors échouer. Dans les deux cas de la surveillance et de la commande, le nom d’un objet retourné par une opération doit être identique au nom demandé par une opération.

6. Définitions

RFC1155-SMI DEFINITIONS ::= DEBUT

EXPORTS -- TOUT

internet, directory, mgmt,

experimental, private, enterprises,

OBJECT-TYPE, ObjectName, ObjectSyntax, SimpleSyntax,

ApplicationSyntax, NetworkAddress, IpAddress,

Counter, Gauge, TimeTicks, Opaque;

-- chemin de la racine

IDENTIFIANT D’OBJET internet ::= { iso org(3) dod(6) 1 }

IDENTIFIANT D’OBJET directory ::= { internet 1 }

IDENTIFIANT D’OBJET mgmt ::= { internet 2 }

IDENTIFIANT D’OBJET experimental ::= { internet 3 }

IDENTIFIANT D’OBJET private ::= { internet 4 }

DENTIFIANT D’OBJET enterprises I::= { private 1 }

-- définition des types d’objet

OBJECT-TYPE MACRO ::=

DEBUT

TYPE NOTATION ::= type "SYNTAX" (TYPE ObjectSyntax)

"ACCESS" Accès

"STATUS" Statut

VALUE NOTATION ::= valeur (VALEUR ObjectName)

Accès ::= "lecture-seule"

| "lecture-écriture"

| "écriture-seule"

| "non-accessible"

Statut ::= "obligatoire"

| "facultatif"

| "obsolète"

FIN

-- noms des objets dans la MIB

ObjectName ::=

IDENTIFIANT D’OBJET

-- syntaxe des objets dans la MIB

ObjectSyntax ::=

CHOIX {

simple

SimpleSyntax,

-- noter que les simples SEQUENCE ne sont pas mentionnées directement ici par souci de simplicité (c’est-à-dire,

-- empêcher de mauvais usages). Cependant, les types valables pour toute une application qui sont IMPLICITEMENT de

-- simples SEQUENCE codés peuvent apparaître dans le CHOIX suivant valable pour l’application.

ApplicationSyntax

}

SimpleSyntax ::=

CHOIX {

number

ENTIER,

string

CHAINE D’OCTETS,

object

IDENTIFIANT D’OBJET,

empty

NUL

}

ApplicationSyntax ::=

CHOIX {

address

NetworkAddress,

counter

Counter,

gauge

Gauge,

ticks

TimeTicks,

arbitrary

Opaque

-- les autres types valables pour toute une application, seront ajoutés ici, à mesure qu’ils seront définis.

}

-- types valables pour toute une application

NetworkAddress ::=

CHOIX {

internet

IpAddress

}

IpAddress ::=

[APPLICATION 0] -- dans l’ordre des octets du réseau

CHAINE D’OCTETS IMPLICITE (TAILLE (4))

Counter ::=

[APPLICATION 1]

ENTIER IMPLICITE (0 à 4 294 967 295)

Gauge ::=

[APPLICATION 2]

ENTIER IMPLICITE (0 à 4 294 967 295)

TimeTicks ::=

[APPLICATION 3]

ENTIER IMPLICITE (0 à 4 294 967 295)

Opaque ::=

[APPLICATION 4] -- valeur ASN.1 arbitraire,

CHAINE D’OCTETS IMPLICITE -- "double enveloppement"

FIN

7. Remerciements

Le présent mémoire a été influencé par trois ensembles de contributeurs à des projets antérieurs :

Tout d’abord, Lee Labarre de MITRE Corporation, qui, comme auteur de NETMAN SMI [4], a présenté la feuille de route de base du SMI.

Ensuite, plusieurs individus qui ont fourni des commentaires précieux sur le présent mémoire avant sa distribution initiale :

James R. Davin, Proteon

Mark S. Fedor, NYSERNetCraig Partridge, BBN Laboratories

Martin Lee Schoffstall, Rensselaer Polytechnic Institute

Wengyik Yeong, NYSERNet

Enfin le groupe de travail MIB de l’IETF :

Karl Auerbach, Epilogue Technology

K. Ramesh Babu, Excelan

Lawrence Besaw, Hewlett-Packard

Jeffrey D. Case, University of Tennessee at Knoxville

James R. Davin, Proteon

Mark S. Fedor, NYSERNet

Robb Foster, BBN

Phill Gross, The MITRE Corporation

Bent Torp Jensen, Convergent Technology

Lee Labarre, The MITRE Corporation

Dan Lynch, Advanced Computing Environments

Keith McCloghrie, The Wollongong Group

Dave Mackie, 3Com/Bridge

Craig Partridge, BBN (chair)

Jim Robertson, 3Com/Bridge

Marshall T. Rose, The Wollongong Group

Greg Satz, cisco

Martin Lee Schoffstall, Rensselaer Polytechnic Institute

Lou Steinberg, IBM

Dean Throop, Data General

Unni Warrier, Unisys

8. Références

[1] Organisation mondiale de normalisation, "Système de traitement de l’information – Interconnexion des systèmes ouverts, spécification de la Notation de syntaxe abstraite n° 1 (ASN.1)", Norme internationale 8824, décembre 1987.

[2] K. McCloghrie et M. Rose, "Base de données d’informations de gestion pour la gestion de réseau des internets fondés sur TCP/IP", RFC 1156, Performance Systems International and Hughes LAN Systems, mai 1990.

[3] J. Case, M. Fedor, M. Schoffstall et J. Davin, "Protocole simple de gestion de réseau", RFC 1157, University of Tennessee at Knoxville, Performance Systems International, Performance Systems International, et MIT Laboratory for Computer Science, mai 1990.

[4] L. LaBarre,"Structure et identification des informations de gestion pour l’Internet", note de travail de la Internet Engineering Task Force, Network Information Center, SRI International, Menlo Park, California, avril 1988.

[5] V. Cerf, "Recommandations de l’IAB pour le développement des normes de gestion de réseau de l’Internet", RFC 1052, IAB, avril 1988.

[6] V. Cerf, "Rapport du second groupe ad hoc de révision de la gestion de réseau", RFC 1109, IAB, août 1989.

[7] Système de traitement de l’information – Interconnexion des systèmes ouverts, "Spécification des règles de codage de base pour la notation de syntaxe abstrait n° 1 (ASN.1)", Organisation internationale de normalisation, Norme internationale 8825, décembre 1987.

Considérations pour la sécurité

Les questions de sécurité ne sont pas discutées dans le présent mémoire.

Adresse des auteurs