Disponible à / Available at permalink :

- - -

- - -

Dépôt Institutionnel de l’Université libre de Bruxelles / Université libre de Bruxelles Institutional Repository

Thèse de doctorat/ PhD Thesis Citation APA:

Idrissi Kaitouni, B. (1990). Réalisation d'un transfert de fichiers OSI dans un environnement de réseau X.25. Organisation fonctionnelle et architecture (Unpublished doctoral dissertation). Université libre de Bruxelles, Faculté des sciences, Bruxelles.

Disponible à / Available at permalink : https://dipot.ulb.ac.be/dspace/bitstream/2013/213144/1/2a0567dc-045b-4ff0-8b1e-ff97b8c92f8e.txt

(English version below)

Cette thèse de doctorat a été numérisée par l’Université libre de Bruxelles. L’auteur qui s’opposerait à sa mise en ligne dans DI-fusion est invité à prendre contact avec l’Université (di-fusion@ulb.be).

Dans le cas où une version électronique native de la thèse existe, l’Université ne peut garantir que la présente version numérisée soit identique à la version électronique native, ni qu’elle soit la version officielle définitive de la thèse.

DI-fusion, le Dépôt Institutionnel de l’Université libre de Bruxelles, recueille la production scientifique de l’Université, mise à disposition en libre accès autant que possible. Les œuvres accessibles dans DI-fusion sont protégées par la législation belge relative aux droits d'auteur et aux droits voisins. Toute personne peut, sans avoir à demander l’autorisation de l’auteur ou de l’ayant-droit, à des fins d’usage privé ou à des fins d’illustration de l’enseignement ou de recherche scientifique, dans la mesure justifiée par le but non lucratif poursuivi, lire, télécharger ou reproduire sur papier ou sur tout autre support, les articles ou des fragments d’autres œuvres, disponibles dans DI-fusion, pour autant que :

Le nom des auteurs, le titre et la référence bibliographique complète soient cités;

L’identifiant unique attribué aux métadonnées dans DI-fusion (permalink) soit indiqué;

Le contenu ne soit pas modifié.

L’œuvre ne peut être stockée dans une autre base de données dans le but d’y donner accès ; l’identifiant unique (permalink) indiqué ci-dessus doit toujours être utilisé pour donner accès à l’œuvre. Toute autre utilisation non mentionnée ci-dessus nécessite l’autorisation de l’auteur de l’œuvre ou de l’ayant droit.

--- English Version ---

This Ph.D. thesis has been digitized by Université libre de Bruxelles. The author who would disagree on its online availability in DI-fusion is invited to contact the University (di-fusion@ulb.be).

If a native electronic version of the thesis exists, the University can guarantee neither that the present digitized version is identical to the native electronic version, nor that it is the definitive official version of the thesis.

DI-fusion is the Institutional Repository of Université libre de Bruxelles; it collects the research output of the University, available on open access as much as possible. The works included in DI-fusion are protected by the Belgian legislation relating to authors’ rights and neighbouring rights.

Any user may, without prior permission from the authors or copyright owners, for private usage or for educational or scientific research purposes, to the extent justified by the non-profit activity, read, download or reproduce on paper or on any other media, the articles or fragments of other works, available in DI-fusion, provided:

The authors, title and full bibliographic details are credited in any copy;

The unique identifier (permalink) for the original metadata page in DI-fusion is indicated;

The content is not changed in any way.

It is not permitted to store the work in another database in order to provide access to it; the unique identifier (permalink) indicated above must always be used to provide access to the work. Any other use not mentioned above requires the authors’ or copyright owners’ permission.

ci) O

UNIVERSITE LIBRE DE BRUXELLES Faculté des Sciences Appliquées

REALISATION D’UN TRANSEERT DE EICHIERS OSI DANS UN

ENVIRONNEMENT DE RESEAU X.2S

Organisation fonctionnelle et architecture

Thèse présentée en vue de l’obtention de grade de Docteur en Sciences Appliquées

Bahia IDRISSI KAITOUNI

Epouse KHALIL

UNIVERSITE LIBRE DE BRUXELLES Facul-té des Sciences Appliquées

REALISATION D’ UN TRANSTERT DE EICHIERS OSI DANS UN

ENVIRONNEMENT DE RESEAU X.2S

OrgamisaLion fonctionnelle et architecture

Thèse présentée en vue de 1’ obtention de grade de Docteur en Sciences Appliquées

Bahia IDRISSI KAITOUNI

Epouse KHALIL

/\ I

:

A toute ma famille

A la mémoire de mon père

F? e? mee r^' ± tnez; in't

Je tiens à remercier Messieurs les Ministres Marocains de l’Education Nationale et de la Formation des Cadres de m’ avoir accordé un détachement pour péparer cette thèse. Je remercie également la Direction de 1’ Ecole Mohammedia d’Ingénieurs qui a su combler mon absence à L’E.M.I durant ces quatre dernières années.

Je remercie beaucoup Monsieur le Professeur O. BEAUFAY5 d’avoir accépté de juger mon travail et présider le jury de cette thèse.

Malgé ses grandes et diverses résponsabilités, Madame Le Professeur F. D’HAUTCOURT a bien voulu accépter de diriger cette thèse. En m’accueillant au sein du service Réseaux et en me proposant un sujet d’actualité> elle m’a permis d’acquérir une expérience variée et très enrichissante. Depuis le début jusqu’à la fin de cette thèse, elle a toujours su, dans mes moments de confusion, réorienter la direction de mes travaux. Je suis très heureuse de lui exprimer ici ma grande admiration et toute ma reconnaissance.

Messieurs les Professeurs C. MACHGEELS, M.

THEYS et P. VAN BINST qui avez bien voulu accépter

de juger ce travail, je vous en remercie et je vous

Mes remerciements vont également à Monsieur le Professeur M.DIAZ> directeur de recherche au Laboratoire d’Automatique et d’Analyse des Systèmes (LAAS) à l’Université de TOULOUSE et sans lequel je n’aurai pu profiter des résultats du projet européen SEDOS/ESPRIT.

Madame M.P, SPINETTE, responsable de l’ordinateur PRIME 9950 a bien voulu mettre à ma disposition toute la documentation concernant ”sa”

machine; je la remercie vivement pour sa patience et sa disponibilité.

L’ aide de Madame M.A. GALMART et de Monsieur Y.

GODELET résponsables Réseau et Système chez PRIME Computer Benelux m’a été très appréciable. Je les remercie pour leur disponibilité et pour tous les éclaircissements concernant les fonctionnements internes de PRIM05 et de PRIMNET.

Mes amis A. COHEN et G. MELARD m’ ont toujours témoigné une grande et sincère amitié. Je les remercie pour leur soutien moral et pour leur apport concret lors de la mise en forme de cette thèse.

Une thèse, c’est un travail d’équipe. Je suis très heureuse d’exprimer tous mes remerciements à.

tous ”les anciens” du Service Réseaux : J.M. FERON,

L.LIBERT, G.THOOFT, ainsi que D.TRUONG pour leur

collaboration.

Je remercie égalenœn-t toute l’équipe actuelle des chercheurs Réseaux qui a fait preuve de beaucoup de compréhension et de tolérance durant ces derniers temps, en particulier, mon collègue et ami 5. XIE pour toutes ses remarques critiques et pertinentes lors de la rédaction de cette thèse.

Je ne saurais oublier Geneviève et Hélène. Je les remercie pour leur serviabilité spontanée, pour' leur efficacité et pour leur contribution à la mise en page de cette thèse. Je remercie également Brigitte d’avoir toujours su me retrouver les documents "égarés”.

Quand à mon mari, je suis vraiment très reconnaissante pour toutes les preuves de soutien et tous les sacrifices qu’il a consenti à faire afin de me permettre d’arriver jusqu’au bout.

Devant ma fille IMANE qui a fait, malgré ses petits six ans et demi, preuve de beaucoup de patience et de maturité, je suis pleine d’admiration et de fierté.

Enfin, je suis très heureuse d’exprimer toute

ma gratitude envers ma famille au Maroc, et en

particulier envers Maman qui a suivi avec bonheur

et angoisse 1’avancement de mes travaux durant

cette dernière année.

En ■terminant cette thèse, mon séjour en Belgique prend fin. A Bruxelles, j’ai connu de merveilleux moments et aussi d’autres, beaucoup et de loin, moins gais. Ces derniers font désormais partie du passé, un passé qu j’ai oublié à jamais.

Et de Bruxelles, je ne garderai que le merveilleux souvenir de tous ceux qui ont contribué, de loin ou de près, à l’aboutissement de cette thèse.

A tous. Professeurs, Famille, Amis, et

Collègues je dis : UN GRAND MERCI.

"TABL-E DES MATIERES

INTRODUCTION 1

Chapitre I

Le fichier virtuel : le concept de baise du protocole 11 FTAM

1.1 Introduction 11

1.2 Description des fichiers virtuels 12 1.2.1 Le modèle hiérarchique général 14

1.2.2 Contextes d’accès 15

1.2.3 Manipulation des fichiers virtuels 16 1.2.4 Description du contenu du fichier 17 1.2.5 Contrôle d’accès et gestion des accès

concurrents 18

1.2.6 Groupes d’attributs 19

1.2.7 Structures d’accès des fichiers classiques 20 1.3 Définition du Service Fichier 21 1.3.1 Traitement des erreurs et qualité de service 22 1.3.2 Régimes du service fichier 23

1.3.3 Services offerts 24

1.3.4 Unités fonctionnelles 24

1.3.5 Classes de service 25

TABLE DES MATIERES

I.4 Mécanismes du protocole FTAM 27 1.4.1 Négociation des classes de service 28 1.4.2 Négociation des unités fonctionnelles 29 1.4.3 Concaténation des Unités de données

du protocole 30

1.4.4 Transparence des données Utilisateur 30 1.4.5 Diagnostics et Résultats 31 1.4.6 Mécanismes de recouvrement des erreurs 32

I. 5 Conclusion 34

Chapitre II

Le Transfert de Fichiers dans l’architecture normalisée

II. 1 Introduction 45

II. 2 Le Niveau ^plication 47

11.2.1 La sélection au niveau de FTAM 47

11.2.1.1 Sélection des Unités fonctionnelles 47

II. 2.1.2 Sélection des paraimétres 49 11.2.1.2.1 Etablissement du régime FTAM 49 11.2.1.2.2 Terminaison normale du régime FTAM 51 11.2.1.2.3 Terminaison anormale du régime FTAM 51 11.2.1.2.4 Sélection d’un fichier 52 11.2.1.2.5 Création d’un fichier 52

11.2.1.2.6 Accès au fichier 53

11.2.1.2.7 Accès au contenu du fichier 54 11.2.1.2.8 Recouvrement des erreurs 56

II.2.2 La sélection de l’ASE ACSE 57

TABLE DES MATIERES

II.3 Le Niveau Présentation 59

11.3.1 Le rôle du Niveau Présentation 59

11.3.2 Le Service Présentation 60

11.3.2.1 Spécification du Service Présentation 60 11.3.2.2 Les unités fonctionnelles 61

II.3.3 Proposition des contextes de Présentation 62 et des UFs

II. 3.3.1 Les syntaxes a±>straites 62 11.3.3.2 La syntaxe de transf ert 63 11.3.3.3 Unités fonctionnelles Présentation 63

II.4 Le Niveau Session 63

11.4.1 Présentation générale 63

11.4.1.1 Concept de Jeton 64

11.4.1.2 Synchronisation! Unité de dialogue et 65 Activité

11.4.1.3 La Resynchronisation 66 II.4.2 Spécification du service Session 67

11.4.2.1 Etablissement de la connexion session 67 11.4.2.2 Phase de traj^fert des données 67 11.4.2.3 Phase de la libération de la connexion 69 11.4.2.4 Unités fonctionnelles 70

11.4.2.5 Sous-ensembles 71

II.4.3 Proposition des unités fonctionnelles 72

TABLE DES MATIERES

11.5 Le Niveau Transport 74

11.5.1 Présentation générale du Service

de Transport 74

11.5.2 Caj~actéristiques du Protocole Transport 75

11.5.2.1 Classification des connexions Réseau 76 11.5.2.2 Caractéristiques des classes du Protocole

de Transport 77

- Fonctions de la classe O 77 - Fonctions de la classe 1 77 - Fonctions de la claisse 2 77 - Fonctions de la classe 3 78 - Fonctions de la classe 4 78

II.5.3 Proposition de la classe du Protocole 79 de Transport

11.6 Conclusion 79

Chapitre III

Les FDTs, pour la Description Formelle des protocoles et leur Validation

111.1 Introduction 89

111.2 Principaux concepts d’Estelle 92

111.2.1 Concept de module 93

111.2.2 Structuration et Parallélisme 95

II1.3 Description du protocole Transport 96

111.3.1 Structure de la spécification 97

111.3.2 Fonctionnement du S 3 ^téme 98

II 1.3.3 Critiques de la spécification de baise lOl

TABLE DES MATIERES

111.4 Réalisation d’un outil de Validation 102 111.4.1 Architecture fonctionnelle du noyau 103 111.4.2 Codage en C de la spécification 104 111.4.3 la Validation par simulation 105

111.5 Conclusion 106

Chapitre IV

Présentation des données et architecture des systèmes ouverts

IV.1 Introduction 112

IV.2 Présentation des données dans les S 3 ^tèmes 113 Ouverts

IV.2.1 Ssmtaxe locale et S 3 mtaxe de Transfert 113

IV.2.2 Représentaion locale 115

IV.2.3 Proposition de structures internes

associées à une valeur ASN/1 116 IV. 2.4 Procédxire d’encodage d’une valeur ASN/1 117 IV.2 5 Procédure de décodage d’une valeur ASN/1 117

IV.2.6 Conclusion 118

IV.3 Architecture des systèmes ouverts 119 IV.3.1 Réalisation des automates A états finis 119 IV.3.2 Implantation des entités des protocoles 120

IV. 4 Les Modèles de base des systèmes de

Communication multi-niveaux 121

IV.4.1 Le ”Server Model” 122

IV.4.2 Le modèle Estelle 123

IV. 4.3 Problèmes des mécaLnismes de communication 123

TABLE DES MATIERES

IV. 5 Un Modèle pour les sys'tèmes ouverts 126

IV.6 Adaptation du modèle è la PRIME 0950 127 IV.6.1 Gestion des connexions 127 IV.6.2 L’interface avec le Réseau 129 IV.6.3 Les modules multi-tâches, les ”Downcalls”

et les "Upcalls” 130

IV.7 Conclusion 131

CONCLUSION 133

TABLE DES MATIERES

F' I GURES

1.1 Le modèle hiérarchique général 37

1.2 La structure Triviale 37

1.3 Représentation des fichiers séquentiels 38 1.4 Représentation des fichiers relatifs et indexés 38

1.5 Nature du Service Fichier 39

1.6 Imbrication des régimes 40

1.7 Tsrpes des protocoles 41

1.8 Procédure de recouvrement des erreurs de classe I 42 1.9 Procédure de recouvrement des erreurs de classe II 42 1.10 Procédure de recouvrement des erreurs de classe III 43 1.11 Représentation des fichiers è index multiples 44

11.1 Enchaînement des primitives de la procédure WRITE 85 11.2 Enchaînement des primitives de la procédure READ 86 11.3 Envoi d’un fichier vers un site distant 87 11.4 Exemple de structuration d’une unité de dialogue 88

11.1 Une structure d’activité 88

111.1 Structure de la spécification Transport

Classe 2 llO

111.2 Organisation fonctionnelle d’un outil de

validation des spécifications Estelle 111

TABLES

II.l Le ”Document type” FTAM-1 82

II. 2 Le ”Document t 3 ^pe” FTAM-3 83

11.3 L’ ”Unstructured constraint set” 84

TABLE DES MATIERES

Spécification des principaux éléments du protocole FTAM

Anne >ce 13

Une présentation générale du langaige Estelle

ANNEXE C

Codage et décodaige des structures ASN/1

ANNEXE D

L*interface Réseau de PRIMENET

BIBLIOGRABHIE

ÆEEND I CE T

Un résumé de la Notation ASN/1

ÆEEND I CE 2

La syntaxe abstraite FTAM_PCI

I NTRODUCT-I ON

Avec l’appajrition des Réseaux, l’hétérogénéité des systèmes informatiques constituait un obstacle qui s’opposait à leur interconnexion, et que 1’ ISO (International Organisation for Standarization) s’est proposé de vaincre en définissant le modèle de référence CISO-74983.

<3e modèle est défini d’une manière purement conceptuelle; il est organisé en sept couches numérotées de là 7, et pour chaque couche deux normes (au moins) sont disponibles. La première décrit les services offerts à la couche supérieure, et la deuxième spécifie le protocole c[ui est censé fournir ces services, en utilisant ceux de la couche inférieure.

Le modèle permet 1’ interconnexion des systèmes réels et ”ouverts” (OSI, Open Systems

Interconnection). Le mot ”ouvert” qualifie tous les systèmes réels qui communiquent conformément aux standards OSI .

D’une manière très succincte, les fonctionnalités des 4 couches inférieures (i.e. les couches Physique, Liaison de données. Réseau, et Trajisport ) concernent le trajisport de 1’ information, tandis que les 3 supérieures (Session, Présentation et Application) permettent son traitement.

Le niveau Application, le plus élevé des sept

niveaux de l’architecture OSI, a été conçu pour

permettre une complète communication entre

utilisateurs distants; ceci grâce aux fonctions

INTRODUCTION

Contrairement aux niveaux inférieurs qui ont atteint une stabilité durable, ce niveau Cainsi que les deux qui lui sont immédiatement inférieurs) est en pleine effervescence. D’une architecture en sous-couches, il est passé (fin 87) à une architecture maillée. Et c’est ainsi, qu’il se présente actuellement sous la forme d’un ensemble de ASEs (Application Service Elément) auxquels une application particulière fait appel, en série, pour demander des services généraux (ACSE, Association Control Service Elément) ou spécifiques (MHS, Message Handling System, FTAM^File Transfer, Access and Management, etc . . . ) .

Le protocole FTAM [ISO-8571] représente, par ordre d’importance, le deuxième ASE derrière la messagerie électronique (MHS). Il permet le transfert et la manipulation des fichiers à distance. La manipulation permet de lire, d’écrire, d’insérer et d’éxtraire des données sur un fichier distant. Ces fonctions associées è la possibilité de création, de destruction, de protection font de FTAM un protocole con^let pour la manipulation des fichiers è distance.

Au sein du service Réseaux de L’ Université Libre de Bruxelles, L’étude du protocole FTAM en vue de son installation sur les différentes machines de l’ULB, (avec la PRIME 9950 comme première machine cible) constitue un axe de recherche, et notre présent travail représente une contribution à cette étude.

L’hétérogénéité des systèmes réels se répercute

sur les organisations des fichiers et sur les

techniques utilisées pour la représentation des

données qu’ils contiennent. Par conséquent, avant

la spécification d’un protocole standard pour la

manipulation des fichiers à distance, L’ISO a

INTRODUCTION

défini un modèle de fichier "universel”, auqpjel les différents méca.nismes du protocole FTAM doivent être appliqués. Ce fichier est le fichier virtuel, et son organisation standard va donc jouer un rôle d’intermédiaire entre la structure de l’émettexir et celle du récepteur pour toutes les manipulations des fichiers à distance.

Pour la représentation des données constituant las f ichiers virtuels, la norme [ISO-8571I utilise une notation de syntaxe abstraite ASN/1 tISO-88241.

L’avaj^tage d’une syntaxe abstraite réside dans le fait qu’elle permet de décrire les données indépendamment des techniques utilisées dans les machines réelles pour les représenter. Ceci laisse le libre choix aux différentes machines pour représenter les données, pourvu que leur représentation soit compatible avec la ssmtaxe abstraite, c.è.d qu’elle conserve sa sémantique.

Ce travail est organisé en 4 chapitres.

Le premier chapitre se veut une synthèse critique de la norme [ISO-85713. Nous y donnons une description détaillée des fichiers virtuels en insistant sur la structure d’accès et sur les principaux attributs qui les caractérisent. Nous y décrivons les services offerts par le protocole,les unités fonctionnelles et les différentes classes de service. Et nous y exposons brièvement les fonctions générales du protocole en décrivant les procédures de négociation des unités fonctionnelles et des classes de service,les facilités de reprise ainsi que les mécanismes de recouvrement des erreurs offerts par le protocole.

L’annexe A est un complément de ce premier

INTRODUCTION

protocole FTAM, un bref rappel des notions de base du modèle de réference OSI.

Le Réseau Universitaire RESULB qui relie tous les équipements informatiques de l’ULB est un Réseau de type X.25* et sur notre machine cible nous disposons certes d’une interface avec le niveau paquet de X.25> mais aucun autre logiciel, de niveau supérieur n’est supporté.

Suite à cette constatation, et après l’étude de la norme [ISO-8571I, qui nous a permis de prendre consience de la grande diversité des fonctions qu’elle propose, nous avons dû limiter notre champ d’étude à un noyau du protocole FTAM. Pairmi les services qu’il offre, ceux qui réalisent le transfert intégral d’un fichier nous semblent les plus prioritaires. A p>artir de ce moment là, notre travail consistait, en fait, en une contribution à la réalisation d’un système OSI, déstiné à supporter l’application de transfert de fichiers dans un environnement de Réseau X.25.

Actuellement, il n’existe pas de méthode spécifique pour le développement des protocoles et encore moins pour la réalisation des systèmes OSI tARG-881, [PER-88], CZIM-881. Néanmoins, et dans le cadre de ce travail, nous proposons une démarche globale qui consiste à découper le processus de réalisation en 5 phases principales : une phase de Définition, une phase de Description Formelle, une phase de Conception, une phase de Réalisation, et une phase de Test.

Le chapitre II est consacré à la phase de Définition.

Cette phase consiste, pour nous, à sélectionner

parmi les protocoles des niveaux supérieurs, un

ensemble cohérent de classes et d’unités

INTRODUCTION

fonctionnelles> destinées à supporter l’application qui fait l’objet de notre étude.

L’existence de standards concrets pour chaque niveau> ne rend p>as pour autant, cette sélection d’une nature aisée. D’aibord, pour certains niveaux,

(notamment les niveaux Réseau et Transport) deux t 5 rpes de service sont définis : le service en mode orienté connexion (Connection-mode), et le sevice en mode sans connexion (Ckjnnectionless-mode).

Ensuite, pour un niveau donné, plusieurs classes de protocoles sont définies : rien que pour le service Transport en mode connexion, cinq classes de protocole sont spécifiées. Enfin, et pour les trois niveaux supérieurs, il existe une multitude d’options. En effet, à. ces niveaux, les services sont groupés en unités fonctionnelles ou UFs, les UFs en sous-ensembles (au niveau Présentation et Session), et en classes pour le protocole FTAM.

Parmi ces groupements, un minimum est défini comme obligatoire, pour garantir une certaine compatibilité, et tout le reste est en option!

En somme, notre phase de Définition, exigeait non seulement une parfaite connaissance des différents stamdards, connaissance qui nécessite un important investissement en temps, mais aussi, et surtout, une certaine méthodologie pour assurer la cohérence des classes de service, des UFs, des sous-ensembles et des options retenues.

Pour le niveau Application, la sélection est basée sur la nature et la qualité du service à.

réaliser. Ainsi, après la description de la classe

de service fichier correspondante à notre

application, nous sélectionnons, parmi les unités

fonctionnelles en option celles qui répondent le

mieux aux besoins de cette application et nous

INTRODUCTION

un séquencement paurfait des données. Nous obtenons ainsi le noyau du protocole FTAM à implanter pour réaliser un transfert de fichiers sûr et fiable.

Après l’ASE FTAM, nous exposons les différents services de l’élément du service application ACSE.

Ces services fournissent les fonctionnalités de base pour mettre en communication deux entités application indépendamment de leur localisation [PUG-88], [ISO-8649] et le protocole FTAM leur fait appel pour établir et libérer le régime FTAM.

Pour le niveau Présentation [ISO-88221 CISO-8823D, et étant donné que pour un transfert de fichiers, tous les contextes de présentation peuvent être définis au moment de l’établissement de la connexion Présentation (voir le paragraphe

II.2 du chapitre II), nous nous limiterons au sous- groupe obligatoire.

Au niveau Session IISO-83261 CISO-8327I, les UFs sont proposées ”en vrac”, et nous ne sélectionnons que les unités fonctionnelles qui supportent celles retenues pour le protocole FTAM.

Enfin, c’est le t 3 ^pe de Réseau qui fait partie de notre environnement matériel (Réseau de type X.25), qui justifie, en premier lieu, notre sélection au niveau Transport CIS0-8072I,

tI50-8073].

Après la phase de Définition, nous abordons la phase de la Description Formelle.

La nécessité de cette phase se justifie par la

nature même des normes OSI. En effet, actuellement,

les protocoles OSI sont spécifiés en langage

naturel (généralement l’anglais et quelquefois le

français). La spécification se base sur

l’utilisation des modèles à transition d’états et

plus précisément sur les automates d’états finis et

elle est conçjlétée par* des tables de transition

INTRODUCTION

auxquelles sont associés des prédicats et des actions.

Si ces spécifications peuvent définir ”en gros”

les mécaj^ismes protocolaires, elles ne peuvent pas être, par contre, à la base d’une inçîlantation correcte. D’abord, elles conduisent à de longues descriptions qui peuvent être inconçîlètes, ou au contraire, contenir des redondaj^ces voir même des contradictions tSVO-88], CARG-88]. Ensuite, elles ne sont pas exemptes d’ambiguïtés [CAN-86Ü. Les ambiguïtés sont à 1’origine d’interprétations différentes qui aboutiront, fatalement, à des réalisations incompatibles! Certes, les tables d’états permettent de franchir un pas vers le formalisme des protocoles, mais elles ne lèvent pas pour autant toutes les ambiguïtés (les actions et les prédicats y sont spécifiés en langage naturel).

Enfin, ces descriptions naturelles ne peuvent être validées qu’ ”à la main”, mais le risque de ne pas étudier tous les cas de figure augmente considérablement avec la copmlexité actuelle des protocoles.

Conscients de ces problèmes, les instances de

normalisation se sont rapidement intéressées aux

techniques de description formelle. Les FDTs

(Formai Description Techniques), grâce â leur

formalisme, permettent d’abord de spécifier les

protocoles d’une manière lisible, précise, conq^lète

et non ambiguë. Ensuite ces FDTs s’apprêtent

pairf aitement à des vérif icatons automatiques,

vérifications qui ont le grand avantage de

permettre la détection, et par conséquent la

correction, d’erreurs ”précoces” avant la phase

d’implantation. Le développement des protocoles

nécessite, en effet, un investissement tel qu’il

vaut mieux alxsrder la phase de la Réalisation avec

INTRODUCTION

Au sein de 1’ ISO, Estelle 1150-90741 et LOTOS [IS0-8807] sont les deux techniques actuellement à l’étude et elles sont toutes les deux au stade de DIS. D’un autre côté, le CCITT a développé le langage SDL [SDL-84I qui est largement utilisé dans le monde des télécommunications.

Le chapitre III fait état des résultats de la troisième phase de notre étude. Ils consistent en une contribution à la description formelle, en Estelle, de certaines classes des protocoles sélectionnés, en la réalisation d’un outil pour la validation des protocoles décrits en Estelle, ainsi qu’en une analyse critique du langage Estelle en tant qu’une technique de description formelle des protocoles OSI . Cette analyse nous a p>ermis de mettre en évidence certaines lacunes du langage, auxquelles nous prop>osons des solutions.

L’annexe B donne une présentation générale du langage Estelle.

Avant d’aborder la phase de la Conception, nous nous devions de nous consacrer à un aspect lié à l’organisation fonctionnelle de notre système. En effet, et compte tenu de la nature de l’application qui fait l’objet de notre étude, la représentation des données à 1’intérieur des systèmes ouverts constitue un aspect fondamental que nous explicitons dans la première partie du chapitre IV.

L’utilisation d’une syntaxe abstraite au niveau Application constitue une solution au problème posé par 1’ hétérogénéité des systèmes réels et concernant la représentation des données. De cette manière, chaque système utilisera sa propre syntaxe pour représenter les données pourvu qu’elle soit compatible avec la sémantique de la syntaxe abstraite.

Cependant, p>our communiquer, tous ces systèmes

ouverts doivent utiliser une syntaxe commune ou

INTRODUCTION

S 3 mtaxe de transfert. Par* conséquent > à l’intérieur d’un système ouvert, deux S 3 mtaxes sont mises en jeu : la syntaxe locale et la ssmtaxe de transfert.

La transformation de la syntaxe locale vers la S 3 mtaxe de transfert et la transformation inverse sont des fonctions du niveau Présentation.

Cependant, les normes tISO-8822], CISO-8823D, dans leur état actuel, ne donnent aucune information concernant la manière de réaliser ces fonctions.

La première partie du chapitre IV, constitue une contribution à la réalisation de ces fonctions.

Elle consiste en la représentation d’une valeur A5N/1 sous la forme de deux ax-bres : l’un correspond au type de la valeur, et l’autre représente cette valeur. En se basant sur ces deux arbres, nous décrivons la procédure de passaige de la S 3 mtaxe locale vers la S 3 mtaxe de transfert et la procédure inverse.

L’annexe C donne une présentation générale de la notation A5N/1 ainsi qu’une description des principales règles d’encodage des ts^pes ASN/1.

Dans la deuxième partie du chapitre IV, nous aborderons, enfin la phase de la Conception.

Autrement dit, le long de cette deuxième partie, nous allons nous intéresser aux problèmes liés è la réalisation des systèmes ouverts en général, et nous essaierons, dans notre contexte, de leur proposer un début de solution. Ces considérations constituent ”a local implémentation matter” dans les standards OSI, et elles sont laissées, par conséquent, à l’initiative du réalisateur.

Pour alxjrder convenablement cet aspect

INTRODUCTION

sélectionnée), après quoi nous proposons une architecture multi-niveaux pour les systèmes OSI en général, et pour le notre en particulier.

En se basant sur les principaux modèles utilisés pour la conception des systèmes de communication multi-niveaux CMUL-88], [SVO-88],

[PUG-89], nous proposons un modèle pour la réalisation de notre système sur la machine cible.

Le modèle prend en compte la nature synchronisée des protocoles des niveaux supérieurs, mais il a été limité par le niveau, modeste, des mécanismes d’ IPC (InterProcesse Communication), offerts par PRIMOS, 1’OS de notre machine cible.

En proposant ce modèle, nous définissons l’architecture de communication de notre système en spécifiant la nature des interfaces et le mécanisme de communication entre les niveaux adjacents, /^rès quoi, nous terminons complètement la phase de la Conception.

L’annexe D donne une description de 1’ interface Réseau qu’offre PRIMNET ainsi que les gramdes lignes pour son utilisation par la couche Traj^port.

En guise de conclusion, nous discuterons d’alxsrd des deux phases que nous n’ avons pas pu

”atteindre” dans le cadre de ce travail, et nous

terminons par un essai méthodologique, qui è partir

des spécifications ”universelles” OSI, permettra

d’aboutir è des implantations correctes et aussi

compatibles. Cette compatibilité incluera le choix

de certains ” local implémentation matters”.

Cl^aLiz>i "t t~ I

Le fid^ietT' viir"tvj.eX : Le c= e n-Cî e i=>“t de fc>ase du ïz>t~o-t oee 1 e

LTAM

I.1 Introduction

Le protocole FTAM (File Transfer Access and Management) est le protocole standard décrit par 1* ISO dans le cadre de 1’ interconnexion des systèmes ouverts [ISO-8571I. Ce protocole permet le transfert, l’accès et la gestion des fichiers à distance.

L’ hétérogénéité des s 3 rstèmes réels se répercute sur les orgamisations des fichiers et sur les techniques utilisées pour la représentation des données qu’ils contiennent. Par conséf^uent, avant la spécification d’un protocole standard pour la manipulation des fichiers à distance, il fallait définir un modèle de fichier ”universel”, auquel les différents mécanismes du protocole doivent être appliqués. Ce fichier est le fichier virtuel, et son organisation standard va donc jouer un rôle d’intermédiaire entre la structure de l’émetteur et celle du récepteur pour toutes les manipulations des fichiers à distance.

Pour la représentation des données constituant

Chapitre I

fai-t qu’elle permet de décrire les données indépendamment des techniques utilisées dans les machines réelles pour les représenter. Ceci laisse le libre choix aux différentes machines pour représenter les données> pourvu que leur représentation soit compatible avec la syntaxe abstraite, c.à.d qu’elle conserve la sémantique de la syntaxe abstraite.

Dans ce premier chapitre, nous allons nous consacrer aux différents aspects de la norme

[ISO-8571]. Dans un premier temps nous donnons une description détaillée des fichiers virtuels en insistant sur la structure d’accès et sur les principaux attributs qui les caractérisent.

La deuxième partie de ce chapitre est réservée à la définition du service fichier. Nous y décrivons les services offerts par le protocole, les unités fonctionnelles et les différentes classes de service.

Enfin daxis la troisième partie nous exposons brièvement les fonctions générales du protocole en décrivant les procédures de négociation des unités fonctionnelles et des classes de service, les facilités de reprise ainsi que les mécanismes de recouvrement des erreurs offerts par le protocole.

Nous terminons ce chapitre par des remarques d’ordre critique concernant 1’ aspect sécurité et la gestion des accès concurrents. Nous concluons en mettant en évidence les limitations du modèle hiérarchique général, limitations qui nécessitent une révision de la version actuelle du protocole FTAM.

1.2 Description des fichiers virtuels

Chapitre I

Description des fichiers virtuels

Un fichier- virtuel est caractérisé par un ensemble de valeurs d’attributs. Les attributs fournissent des renseignements concernant l’identification du fichier (Filename), son organisation, sa manipulation, et les types des données qu’il contient (Contents type), sa gestion (Identity of creator. Date and Time of création,...), et ils spécifient les conditions d’accès au fichier (Access control).

Pour pouvoir séparer les caractéristiques statiq[ues et dynamiques d’un fichier virtuel, les attributs sont groupés en deux classes :

- les attributs de fichier (file attributes):

ils décrivent l’aspect statique du fichier; leur valeur est globale en ce sens qu’ à tout instant elle est identique pour tous les utilisateurs du fichier (nom du fichier, structure d’accès, nature des données constituant le fichier, actions de manipulation du fichier etc...).

les attributs d’activité ”activity attributes” : ce sont des attributs djmamiques en ce sens que leur valeur peut changer d’une activité à une autre. Par conséquent, ils fournissent des informations concernant le fichier durant une activité précise. Cette classe est constituée des attributs actifs ”active attributes” qui indiquent, parmi les attributs de fichier, ceux qui sont effectivement utilisés, et des attributs en cours d’utilisation ”current attributes” qui reflètent l’état de progression de l’activité, et qui sont construits à partir des paramètres des primitives de service échangées dans les éléments du protocole (typ>e d’accès requis, position dans le fichier, etc...).

Chaque attribut a un type et une valeur; trois

types d’attributs sont définis :

Chapitre I

Description des fichiers virtuels

- les attributs de t 5 ^pe liste "vector attributes” ont des valeurs constituées par des listes ordonnées d’éléments; et

les attributs de type ensemble ”set attributes” qui ont des valeurs constituées par un ensemble de plusieurs éléments.

Les types des valeurs de base des attributs (entier> booléen, séquence d’octets, séquence de caractères) sont définis dans [ISO-8824] au moyen de la notation ASN/1 ; d’autres t 3 rpes sont introduits pour répondre aux besoins spécifiques du protocole FTAM (”application entity title”

CIS0-8650], ”date and time” [IS0-8601]).

La liste complète et détaillée des attributs est donnée en Annexe A.1 ; cependant, nous allons détailler dans ce qui suit ceux qui nous semblent les plus significatifs.

1.2.1 Le modèle hiérarchique général

Les fichiers virtuels sont constitués d’un

ensemble d’unités de données (Data Unit ou DU)

structurées hiérarchiquement. Plus précisément, la

structure d’accès est définie en CISO-8571-21 comme

un arbre ordonné selon l’ordre ”préorde”; les

différents noeuds de 1’ arbre peuvent être

identifiés par des noms et au maximum une DU peut

être attachée à un noeud. Chaque noeud donne accès

au sous-arbre dont il est la racine et chaque sous

arbre ou FADU (File Access Data Unit) constitue une

unité d’accès au fichier. Des valeurs entières

positives sont associées aux arcs, et aucune

restriction n’est spécifiée ni sur le nombre des

niveaux de l’arbre, ni sur les valeurs associées

aux arcs. Pratiquement un FADU, comme le montre la

figure I.l peut représenter un enregistrement, un

fichier, une sous-Directory ou une Directory.

Chapitre I

Description des fichiers virtuel

Cette structure d’accès est appelée le modèle hiérarchique général et elle peut représenter une grande variété de structures pratiques supportées par les systèmes réels. En réalité, il n’est pas nécessaire d’utiliser le modèle dans toute sa généralité pour représenter toutes les structures courantes (fichiers textes ou binaires, fichiers séquentiels, relatifs et indexés). En effet; et comme nous allons le voir dans le paragraphe 1.2.7, tous ces fichiers classiques peuvent être représentés par une structure ”flat” c.à.d par un arbre a un seul niveau ou par une structure réduite à la racine et à la DU associée.

1.2.2 Contextes d’accès

Pour préserver la structure d’accès lors d’un transfert, il est nécessaire d’introduire des informations de structuration dans la définition des FADUs qui constituent le fichier. Dans ce sens, la norme CISO-8571] caractérise les FADUs au moyen des éléments suivants :

- un descripteur de noeud qui indique le nom éventuel de la racine du FADU, la valeur de l’arc qui relie cette racine à son père et la présence ou non de DU attachée à cette racine;

- la DU associée è la racine du FADU (si elle existe), et

- l’ensemble des FADUs fils.

Cette définition, faite au moyen de la notation

^N/1 introduit donc des informations de

structuration (les descripteurs des noeuds et les

informations nécessaires pour délimiter les

différents FADUs fils) qui doivent être, elles

aussi transférées le cas échéant (en plus des DUs).

Chapitre I

Description des fichiers virtuels

lecture des DUs par exemple) grâce au concept du contexte d’accès (Access context).Ainsi, lors d’une opération de lecture, le contexte d’accès utilisé spécifie, parmi les éléments qui caractérisent les FADUs, ceux qui doivent être transférés. La définition des contextes d’accès permet donc de transférer les FADUs indépendamment des informations de structuration.

1.2.3 Manipulation des fichiers virtuels

L’accès aux fichiers virtuels peut se faire d’une manière séquentielle ou directe.

Dans le premier cas le parcours du fichier peut se faire du début vers la fin (Traversai), en localisant à chaque fois le FADU suivant, ou dans le sens inverse (Reverse traversai), en localisant le FADU précédant.

Dans le second cas (Random order) l’identification des FADUs repose sur l’ordre de parcours de la structure d’accès et sur les noms attachés aux différents noeuds de cette structure.

Ainsi le FADU à localiser est identifié au moyen du nom qui est attaché â sa racine (single Node- Name), ou en spécifiant une séquence de noms (sequence of Node-Names) qui caractérise le chemin entre le FADU et la racine de la structure d’accès ou par son rang lors de la traversée de la structure d’accès (node number).

D’autre part, les actions de manipulation des

fichiers virtuels sont définies de telle sorte que

toutes les opérations classiques de manipulation

des fichiers ”réels” soient supportées. Ces actions

permettent notamment la création, la suppression,

la sélection, la libération, la gestion du fichier

ainsi que toutes les opérations traitant un FADU

Chapitre I

Description des fichiers virtuels

spécifique. La liste complète de toutes ces actions est donnée en Annexe A.2.

1.2.4 Description du contenu du fichier

L’attribut "Contents type” permet de spécifier les t 5 ^pes des données constituant un fichier virtuel. En fait, cet attribut fournit une collection d’informations relatives è la manipulation d’un fichier; ces informations concernent notamment la structure d’accès et le nom de la syntaxe abstraite utilisée pour représenter le contenu du fichier. Ces informations sont réunies dans un document (document t 3 q>e1 associé à chaque fichier, et c’est le nom de ce document qui représente la valeur de 1’attribut "Contents t 3 q>e”.

La norme CISO-8571] définit 5 "document t 5 q>es”;

mais cette définition ne couvre que des cas simples de fichiers (fichiers textes ou binaires). Un seul

"document type” se veut plus général en ce sens qu’il laisse la spécification de tous les éléments le constituant é. la charge de l’utilisateur, et par sa nature même, on ne peut pas le considérer comme normalisé.

1.2.5 Contrôle d’accès et gestion des accès concurrents

Le mécanisme du contrôle d’accès aux fichiers

virtuels rep>ose sur 1’ utilisation d’une liste de

contrôle d’accès (Access Control List); chaque

entrée de la liste spécifie un ensemble d’actions

et définit les conditions qui doivent être

Chapitre I

Description des fichiers virtuels

La gestion des accès concurrents permet d’exécuter en parallèle et d’une manière cohérente plusieurs actions sur le même fichier; cette gestion est assurée grâce à 1’ utilisation de deux mécanismes différents :

Le premier mécanisme ”File concurrency”

contrôle l’accès â tout le fichier; il peut s’ appliquer au moment de la création ou de la sélection du fichier et il reste en vigueur jusqu’à ce que le fichier soit libéré ou supprimé;

toutefois il peut être modifié durant le régime d’ouverture du fichier. Ce mécanisme consiste en l’association d’une clé à chacune des actions de naanipulation du fichier; ainsi au moment de l’établissement des régimes de sélection ou d’accès au fichier l’initiateur peut spécifier pour chaque clé l’une parmi les valeurs suivantes :

- non requise ”not required” : pour indiquer qu’ il ne va pas exécuter cette action et que les autres utilisateurs peuvent l’exécuter;

- partagée ”shared” : pour indiquer le partage de 1’action;

exclusive ”exclusive” : pour s’assurer l’exclusivité de l’action;

- accès non permis ”no access” : pour interdire 1’exécution de 1’action.

Le deuxième mécanisme (FADU locking) est plus fin que le précédent en ce sens qu’il concerne un FADU spécifique et qu’il ne s’applique que durant l’exécution d’une action d’accès à ce FADU;

1’ utilisation de ce mécanisme n’ est pas obligatoire

et elle est négociée lors de l’établissement du

régime FTAM.

Chapitre I

Description des fichiers virtuels

1.2.6 Groupes d’attributs

Vu la diversité des attributs proposés et dans le but de permettre des implantations ”partielles”

et compatibles, la norme [ISO-8571] définit trois groupes standards d’attributs : le Noyau ”Kernel group”, le groupe de Stockage ”Storage group” et le groupe de Sécurité ”Security group”.

- Le Noyau constitue le groupe obligatoire en ce sens qu’il doit être supporté par toute implantation conforme à la norme CISO-8571]; ce groupe est composé des attributs suivants :

a) Attributs du fichier 1) Filename;

2) Permitted actions;

3 ) Contents t 3 ?pe.

b) Attributs d’activité

1 ) Active Contents t3T3e;

2) Current access request;

3) Current initiator identity;

4) Current location;

5) Current processing mode;

6) Current calling application entity

title;

Chapitre I

Description des fichiers virtuel

Lai liste des attributs constituamt les groupes de stockage et de sécurité est donnée en Annexe A. 3.

1.2.7 Structure d’accès des fichiers classiques

La norme [ISO-8571D définit un ensemble de

”constraint sets” qui correspondent è des cas particuliers du modèle} et pour lesquels sont spécifiées certaines limitations concernant leur mamipulation.

Dans ce paragraphe} nous allons examiner successivement les fichiers textes ou binaires} les fichiers séquentiels} les fichiers relatifs et les fichiers indexés} ceci afin de les représenter en utilisant le modèle hiérarchique général} et de leur associer ”un constraint set” précis.

- Lors d’un transfert intégral d’un fichier texte ou binaire} on peut associer à ces fichiers une structure d’accès réduite à. la racine avec la DU associée. La DU représente tout le contenu des fichiers et la racine n’a pas de nom qui lui est associé} ceci comme le montre la figure 1.2. A cette manipulation} on associe 1’ ”unstructured constraint set”;

- Pour les fichiers séquentiels} la structure d’accès est formée par la racine et par une série de feuilles reliées à la racine par des arcs de valeur 1 et contenant chacune une DU Cvoir figure 1.3). Les DUs représentent les différents enregistrements et l’absence de noms attachés aux différents noeuds ne permet donc qu’un accès séqpjentiel au fichier; pour manipuler ces fichiers}

on utilisera le ”Sequential Fiat constraint set”.

Chapitre I

Description des fichiers virtuels

- Pour les fichiers indexés (avec un seul index) et relatifs, la structure d’accès est identique à la précédente (voir figure 1.4) mais dans ce cas chaque feuille a une DU et un nom qui lui sont attachés. Ainsi 1’ accès à un FADU spécifique peut se faire sur la base de son nom

(clé d’accès) ou sur la base de sa position dans la structure d’accès. Pour ces fichiers, on associe

”l’Ordered Fiat constraint set” ou ”1’Ordered Fiat constraint set with unique names”, selon la nature des clés.

Les trois autres ”constraint sets” consistent en :

- 1’ ”Ordered Hierarchical constraint set” ; que nous explicitons dans le pajragraphe 1.5;

- le ”General Hierarchical constraint set”: qui n’ impose aucune restriction;

- le ”(îeneral Hierarchical constraint set with unique names” : qui modélise les directories;

l’unicité des noms concerne les fils de chaque noeud.

1.3 Déf i hi t ion du Sery ice _ F i çhJL

La description du Service Fichier repose sur le modèle abstrait défini dans tISO/TR 8509);ce modèle fait interagir deux utilisateurs du Service Fichier et le Fournisseur du Service qui communiquent au moyen des Primitives de service.

Le service fichier offert par le protocole FTAM est asyinétrique. En effet, chaque activité de transfert ou d’accès à un fichier distant met en présence trois entités (voir figure 1.5) :

une entité qui contrôle le déroulement de

l’activité, une entité A qui accède au fichier

Chapitre 1

Définition du Service Fichier

Pour simplifier la coordination et le contrôle de transfert; il est assumé que les informations décrivant les fichiers source et destination ainsi que celles concernant le transfert sont passées, par le contrôleur, à une des deux entités soit A.

Cette entité, qui assure elle-même le contrôle du transfert représente 1’ Initiateur en ce sens que c’est elle qui émet les requêtes de manipulation des fichiers. L’autre entité est le Répondeur, et elle ne fait qu’exécuter d’une manière passive les requêtes qui lui sont adressées.

1.3.1 Traitement des erreurs et qualité du service

Pour la détection, la reprise et le recouvrement des erreurs, le protocole FTAM offre deux p>ossibilités qui se traduisent par deux services de qualité différente :

- le service fichier externe (External File Service ou EFS) : à ce niveau toutes les actions de détection, de reprise et de recouvrement des erreurs sont transparentes pour 1’ utilisateur du service en ce sens qu’ elles sont assurées par* le fournisseur du service (ce qui veut dire que la spécification du protocole qui fournit ce service doit inclure nécessairement des procédures de recouvrement);

- le service fichier interne (Internai File Service ou IFS) : fournit aux utilisateurs des moyens pour faire des reprises, suite à. des erreurs, et pour contrôler la pose de points de vérification (ou de reprise).

1.3.2 Régimes du service fichier

Chapitre I

Définition du Service Fichier

Toute activité de traxisfert ou d’accès à un fichier prend place en une succession de quatre régimes imbriqués :

- le régime FTAM (FTAM régime) qui débute au moment où l’association Application est établie entre les deux utilisateurs du service, et qui a la même durée de vie que cette association, (par analogie avec les autres niveaux du modèle de référence, l’établissement du régime FTAM correspond donc à l’établissement de la connexion application);

- le régime de sélection du fichier ( file sélection régime) durant lequel un fichier bien précis est associé au régime FTAM;

- le régime d’accès (file op>en régime) à 1’ intérieur duquel sont précisés les traitements à effectuer sur le fichier;

- le régime de transfert de données (data transfer régime) durant lequel le transfert du fichier - et des informations de structuration éventuellement - ont effectivement lieu.

D’après son fonctionnement, le protocole n’autorise qu’une seule activité de transfert ou d’accès à la fois à l’intérieur d’un régime FTAM;

cependant ce protocole permet d’établir ;

- plusieurs régimes de sélection successifs à 1’ intérieur d’un mên^ régime FTAM (ce qui est fort utile lorsqu’on veut accéder è plusieurs fichiers situés sur le même site distant);

- plusieurs régimes d’accès successifs è 1’ intérieur d’un même régime de sélection de fichier;

- une séquence de régimes de transfert de

données à l’intérieur d’un même régime d’accès au

fichier.

Chapitre I

Définition du Service Fichier

La terminaison d’un régime implique la terminaison de tous les régimes qui sont imbriqués dedans; l’ordre d’imbrication des régimes est illustré dans la figure 1.6.

1.3.3 Services offerts

Le Service Fichier est décrit sous la forme d’un ensemble de ”sous-services” appelés simplement Services.

Les principaux services permettent de contrôler l’établissement et la libération des différents régimes définis ci-dessus et, ils créent, par conséquent et progressivement l’environnement nécessaire pour le fonctionnement du protocole.

Les autres services permettent la gestion des fichiers (services de consultation et de modification des attributs), et le traitement des erreurs (services de pose de point de vérification, d’annulation de transfert, et de reprise).

L’utilisation de ces services se fait au moyen des primitives qui peuvent transp>orter des paramètres.

La liste de tous les services offerts par le protocole est donnée en Annexe A.4.

1.3.4 Unités fonctionnelles

Vu la variété des services proposés et pour

faciliter la procédure de négociation de leur

utilisation lors de l’établissement du régime FTAM,

les services offerts par le protocole FTAM sont

groupés logiquement en unités fonctionnelles

(Functional units). Dix unités fonctionnelles sont

définies dans la norme et elles consistent en :

Chapitre I

Définition du Service Fichier

U1 > le noyau (Kemel functional unit);

U2, l’unité fonctionnelle de lecture (Read functional unit);

U3, l’unité fonctionnelle d’écriture CWrite functional unit);

U4, l’unité fonctionnelle d’accès (File access functional unit);

U5 l’unité fonctionnelle de gestion limitée (Limited file management functional unit);

U6> l’unité fonctionnelle de gestion améliorée (Enlianced file management functional unit);

U7, l’unité fonctionnelle de groupage (Crouping);

U8^ l’unité fonctionnelle de verrouillage des FADUs (FADU Locking functional unit );

U9, l’unité fonctionnelle de recouvrement (Recovery functional unit);

UlO, l’unité fonctionnelle de reprise de transfert (Restart data transfer functional unit).

La spécification des unités fonctionnelles en fonction des services est donnée en Annexe A.5.

1.3.5 Classes de service

La définition des classes de service a pour but

Chapitre I

Définition du Service Fichie

fichier» ceci permet d’at>outir à des implantations partielles et cohérentes du protocole. Les classes standard sont au nombre de cinq et pour des raisons de conformité à la norme [ISO-8571], toute implantation du protocole FTAM doit supporter au moins une parmi ces cinq classes.

Ces classes regroupent des unités fonctionnelles obligatoires et d’autres optionnelles et elles se présentent comme suit :

1) la classe de transfert Cfile transfer class ) : elle est constituée des unités fonctionnelles nécessaires pour assurer un transfert intégral du fichier. Les unités fonctionnelles obligatoires sont U1» U7 et une pairmi U2 ou U3 ; celles cjui ne sont pas permises sont U4 et U8 et toutes les autres unités fonctionnelles restant sont optionnelles.

2 y la classe d’accès (file access class) : cette classe est définie pour permettre l’accès è des FADUs spécifiques du fichier; les unités fonctionnelles obligatoires dans cette classe sont U1> U2, U3 et U4 et toutes les autres sont optionnelles.

3) la classe de gestion (file management class) : le but de cette classe est de permettre la

création» la destruction ainsi que la consultation et la modification des valexirs des attributs du fichier. Les unités fonctionnelles obligatoires sont U1» U5» U6 et U7; toutes les autres ne sont pas permises.

4) la classe de trainsfert et de gestion (file transfer and management class) : cette classe

est une combinaison de la classe de transfert et de

la classe de gestion. Les unités fonctionnelles

obligatoires sont U1» U5» U6» U7 et une parmi U2 ou

U3; celles qui ne sont pas permises sont U4 et U8

et les optionnelles sont U9 et UlO.

Chapitre I

Définition du Service Fichier

5) la. classe sans contraintes (unconstrained class) : dans cette classe seule l’unité

fonctionnelle U1 est obligatoire; toutes les autres étant optionnelles sans aucune restriction.

I.4 Mécanismes du protocole FTAM

La norme CISO-8571-4] spécifie deux typ>es de protocoles : le premier est le protocole de base

(basic protocol) qui fournit le service fichier interne ou IFS; le second est le protocole de recouvrement des erreurs Cerror recovery protocol) qui assure le service fichier externe ou EFS

Cvoir 1.3.1).

Les principales fonctions du protocole de base consistent en la construction des FPDUs à partir des primitives de service> en la transmission de ces FPDUs vers les niveaux inférieurs (voir chapitre II), et en la concaténation de plusieurs FPDUS afin de pouvoir les transmettre en une seule fois.

Le protocole de recouvrement des erreurs fournit le service fichier externe en se basant sur les fonctionnalités du protocole de base. Durant son déroulement normal, ce protocole assure la gestion des informations permettant de faire des reprises de transfert de données après une interruption, et en cas d’incidents, ce même protocole permet de rétablir les régimes d’accès et de sélection de fichier ainsi que le régime FTAM.

Le fonctionnement de chaque t3q3e du protocole (voir figure 1.7) est modélisé par l’interaction de deux machines (File Protocol Machines ou FPMs);

au protocole de base correspondent les machines de

Chapitre I

Mécanismes du protocole FTAM

Recovery Protocol Ffaichines) sont associées au protocole de recouvrement des erreurs.

1.4.1 Négociation des classes de service

L’initiateur spécifie dans le paramètre "classe de service’’ de la primitive F-INITIALIZE request la ou les classes de service qu’ il désire utiliser duramt l’association Application. Il ne peut choisir Cprincipe de conformité è la norme

IISO-8571I) qu’une combinaison parmi les suivantes

•

- la classe de transfert C T )>

- la classe de gestion ( M )>

- la classe d’accès ( A ),

- les classes de transfert et d’accès (T, A ), - les classes de transfert, de gestion et de tramsfert et de gestion C T, M, TM ), et

-les classes d’accès, de transfert, de gestion et de transfert et de gestion (A, T, M, TM ).

Durant la procédure de négociation, le fournisseur de service supprime de cet ensemble

(spécifié par l’initiateur) toutes les classes qu’ il ne supporte pas et signale le reste au répondeur dans le paramètre correspondant de F-INITIALIZE indication.

A son tour, le répondeur peut encore réduire

cet ensemble proposé par le fournisseur de service

en sélectionnant, parmi les classes qu’il est

capable de supporter, celle qui a la plus forte

priorité. L’ordre décroissant des priorités des

classes étant défini comme suit : classe d’accès,

classe de transfert et de gestion, classe de

transfert, classe de gestion et la classe sans

contraintes. C’est cette classe, sélectionnée par

le répondeur, qui va être signalée à l’initiateur,

au moyen de la primitive F-INITIALIZE confirm, et

Chapitre I

Mécanismes du protocole FTAM

qui va être adoptée durant toute la durée de vie du régime FTAM.

1.4.2 Négociation des unités fonctionnelles

La procédure de négociation des unités fonctionnelles se déroule d’une manière analogue à celle adoptée pour les classes de service. En effet et en concordance avec les classes de service souhaitées, l’initiateur propose une liste d’unités foncttonnellesî cette liste doit conç>rendre toutes les unités fonctionnelles obligatoires dans chaque classe et les unités fonctionnelles choisies parmi les options. Les unités fonctionnelles U1, U9 et UlO ne font pas l’objet de cette négociation; en effet l’unité fonctionnelle U1 doit être toujours supportée par toute inçîlantation conforme à la norme tISO-8571] et l’adoption des unités fonctionnelles U9 et UlO relève d’une décision locale basée sur les qualités de services proposées par les niveaux inférieurs et sur la qualité de service du régime FTAM négociée entre les deux utilisateurs du service fichier (voir II.1.2.1).

Le fournisseur de service peut, selon ses capacités, réduire cet ensemble d’unités fonctionnelles; après quoi il transmet l’ensemble restant au répondeur dans le paramètre correspondant de la primitive F-INITIALIZE indication.

Enfin le répondeur sélectionne parmi cet

ensemble les unités fonctionnelles qu’il est

capable de supporter et les signale, au fournisseur

de service, au moyen de F-INITIALIZE response; ce

dernier transmet cet ensemble d’unités

fonctionnelles à l’initiateur au moyen de F-

Chapitre I

Mécanismes du protocole FTAM

être disponible après l’établissement du régime FTAM.

1.4.3 Concaténation des unités de données du protocole

Les FPDUs (File Protocol Data Unit ) sont des types de données très complexes définis d’une manière formelle au moyen de la notation ASN/1 [ISO-8824/2]> cette définition inclut les paramètres des primitives de service et ceux nécessaires au fonctionnement et è la progression du protocole et elle constitue la syntaxe abstraite FTAM_PCI.

Dans un but de simplification de la machine à états qui modélise le protocole, la concaténation de certains FPDUs est obligatoire. Ceci est particulièrement vrai pour la classe de transfert dans laquelle les FPDUs correspondant à l’établissement des régimes de sélection et d’ouverture des fichiers doivent être concaténés ainsi c|ue ceux qui permettent la libération de ces régimes.

Un autre avantage de cette concaténation est lié au délai d’établissement du régime d’accès. En effet, en transmettant tous les FPDUs concaténés en une fois, on contribue à la diminution du délai nécessaire à l’établissement du régime d’accès au fichier.

1.4.4 Transparence des données Utilisateur

Par rapport au fournisseur du service

Présentation, les données de 1’utilisateur du

service fichier ainsi que les informations de

contrôle du protocole FTAM (FTAM_PCI> constituent

Chapitre I

Mécanismes du protocole FTAH

des séries de valeurs de données Présentation (Présentation Data Values ou PDVs). Par conséquent des mécanismes de prévention sont nécessaires pour assurer le transfert, sans ambiguïté, entre les données utilisateur et les informations de contrôle de protocole.

La solution adoptée dans le protocole FTAM repose sur les contextes de présentation

(voir II.2) utilisés pour transmettre ces deux t 3 qaes d’information (un contexte de présentation étant défini comme l’association d’une syntaxe abstraite et d’une S 5 mtaxe de transfert CISO-8822I [ISO-8823I). En effet, à l’intérieur du régime FTAM, le premier contexte de présentation utilisé correspond au transfert des informations du contrôle du protocole (FTAM PCI présentation context) et toutes les autres PDVs, transmises dans n’ importe quel autre contexte peuvent donc être interprétées correctement par les mécanismes du protocole présentation.

1.4.5 Diagnostics et Résultats

Le protocole FTAM fournit les moyens nécessaires pour informer l’utilisateur de l’état de progression du protocole et du succès - ou de 1’échec - des opérations requises. Au plus haut niveau, les deux paramètres Résultat (”State resuit” et ”Action resuit”) donnent des renseignements sur le comportement des FPMs : le

”state resuit” indique le succès ou 1’échec d’une

transition et il n’est présent que dans les

primitives de service qui engendrent un changement

de régime;”l’action resuit” donne le résultat de

l’opération requise et sa valeur peut indiquer un