Le projet MERCURE de communications informatiques à l'UCL
M. Lobelle
Ce document est une version remise à jour le 24 janvier 1990.
Sommaire
- Introduction
- L'interréseau de l'U.C.L.
- Choix, en termes du modèle ISO, du niveau de
l'interconnexion dans l'architecture
- Choix des protocoles pour l'interréseau de
l'U.C.L.
- Architecture de l'interréseau
- Première phase du projet MERCURE
- Interconnexion des réseaux locaux :
l'interréseau
- Nature et localisation du réseau Dorsale de la
première phase
- Connexion des réseaux côtes
- Prospective : Ce que pourrait être un futur
réseau Dorsale en FDDI (fibres optiques)
- Organisation de la gestion de l'interréseau
- Responsabilité de la gestion des réseaux
- Les réseaux côtes
- Les réseaux de troisième niveau et les machines
connectées aux réseaux "côtes".
- Le réseau dorsal et le Service des Réseaux d'Information
- Coordination du choix des adresses de machines sur
l'interréseau U.C.L. - centralisation de l'attribution des identificateurs
des réseaux locaux
- Un service global de courrier électronique pour
l'U.C.L.
- Les besoins
- Architecture d'un système de courrier électronique
- Architecture du système de courrier électronique
de l'U.C.L.
- Traduction des besoins en termes des composants de l'architecture d'un
système de courrier électronique et contraintes
techniques
- L'infrastructure proposée d'acheminement et
d'archivage des messages de 1989 à 1991
- Les UA
- Coordination du choix des noms identifiant les membres
de la communauté universitaire pour le courrier électronique
- Le groupe ILAN
Introduction
Dès 1985, dans le cadre de son Plan Informatique, l'U.C.L. a commencé à
se doter de réseaux locaux d'ordinateurs, rattachés aux installations
informatiques décentralisées Levant, Sciences 1 et Goria. Plusieurs
autres entités de l'U.C.L. ont, depuis, également installé des réseaux
locaux (Unité d'Informatique, Centre de Calcul, Faculté des Sciences
Appliquées pour les activités didactiques, Faculté de Médecine, Faculté
d'Agronomie, Administration Centrale, installations décentralisées LeW et
Croix du Sud, etc.), ou le projettent.
Les réseaux locaux permettent de répondre aux besoins internes de groupes
d'utilisateurs dont les ordinateurs sont connectés au même réseau. Ces
groupes correspondent à des équipes de personnes qui travaillent
ensemble. Les réseaux locaux permettent d'offrir des services, qui ne
pourraient s'envisager sans leur existence, tels que le courrier
électronique, l'utilisation interactive de n'importe quel ordinateur
connecté au réseau (pourvu qu'on y soit autorisé), le partage de
ressources telles que disques et imprimantes, ou les terminaux-X qui
permettent même de travailler simultanément sur plusieurs ordinateurs,
etc. Pour que cette coopération entre ordinateurs soit possible, deux
conditions doivent être remplies :
- les ordinateurs doivent être connectés par un réseau ou un ensemble
de réseaux interconnectés;
- les ordinateurs doivent "parler le même langage" et ce langage doit
pouvoir être transmis à travers le réseau ou l'ensemble de réseaux
interconnectés. Les langages utilisés par les ordinateurs pour
communiquer entre eux sont appelés des protocoles. Il faut que les
ordinateurs coopérant utilisent les mêmes protocoles et il faut que ces
protocoles puissent être transmis à travers le réseau ou l'ensemble de
réseaux interconnectés.
Comme dans toute organisation, les besoins de communication au sein de
l'U.C.L. ne se limitent pas aux groupes de personnes faisant partie d'une
même équipe, quoique les besoins principaux se situent au niveau de
l'équipe. Les besoins de communication informatique entre personnes
d'équipes différentes ne peuvent être satisfaits que si on veille à
prendre des mesures positives pour les satisfaire.
Lors de la réunion du Conseil Académique du 3 octobre 1988, l'U.C.L.
s'est fixé une politique générale en matière de réseaux informatiques
dans le but de permettre la coopération entre tous les ordinateurs de
l'Université et d'offrir aux membres de la communauté universitaire un
ensemble de services globaux de communication informatisée.
La politique choisie laisse à chaque entité un maximum de liberté tout en
définissant un certain nombre de précautions à prendre pour rendre
possible l'accès aux services globaux. Elle définit, par exemple, les
protocoles à utiliser pour communiquer en dehors de chaque équipe, tout
en permettant d'utiliser d'autres protocoles en leur sein. Ce document
présente le projet MERCURE de communications
informatiques à l'U.C.L. Ce projet met en oeuvre la politique choisie.
L'interréseau de l'U.C.L.
L'Université a décidé de se doter d'un moyen de communication
informatique accessible à tous (comme elle se préoccupe d'offrir un
service téléphonique). Un tel moyen de communication est une condition
nécessaire pour permettre l'organisation d'un certain
nombre de services globaux tels que la messagerie électronique, l'accès à
des bases d'information communes, le transfert de fichiers, la
possibilité de se connecter à d'autres ordinateurs (pour autant qu'on y
soit admis comme utilisateur), etc.
Dans la mesure où cela reste compatible avec ce premier objectif, ce
moyen de communication permet également à des ordinateurs utilisant des
protocoles différents de ceux définis pour les services globaux, de
coopérer à travers ce moyen de communication.
Ce moyen de communication informatique global de l'U.C.L. consiste en
l'interconnexion des divers réseaux locaux de l'U.C.L. pour former un
interréseau. (1)
L'existence de ce moyen de communication n'est cependant pas une
condition suffisante : les logiciels utilisés par les différents
interlocuteurs doivent être basés sur les mêmes protocoles.
D'autre part, l'existence de ce moyen de communication impose aux
gestionnaires des systèmes informatiques qui y sont connectés de prendre
les précautions classiques pour garantir la confidentialité des
informations : dès qu'on installe un réseau, chaque gestionnaire de
machine connectée doit prendre les mêmes précautions que s'il plaçait un
terminal connecté à sa machine dans un lieu public, et même davantage.
Choix, en termes du modèle ISO, du niveau de
l'interconnexion dans l'architecture des réseaux de l'U.C.L.
L'ISO (Organisation Internationale de Standardisation) a défini un modèle
auquel on se réfère le plus souvent lorsqu'on discute des problèmes de
réseaux d'ordinateurs. Selon ce modèle de référence, des ordinateurs
communicants utilisent des protocoles organisés en sept couches. Les
protocoles de chaque couche exploitent le service offert par ceux de la
couche immédiatement inférieure et offrent un service plus élaboré à la
couche qui est au-dessus d'eux. Parmi ces couches, deux sont
intéressantes pour la discussion qui suit : la couche 2, baptisée "couche
de liaison de données", qui définit le protocole d'accès au réseau et la
gestion de la communication entre deux ordinateurs connectés
directement, et la couche 3, baptisée "couche du réseau", qui est
chargée de l'acheminement de l'information de la machine source à la
machine destination, éventuellement à travers un certain nombre de
machines intermédiaires et de supports physiques différents.
L'interconnexion de réseaux locaux peut se faire de trois manières
différentes :
- au moyen d'un logiciel situé au niveau 2 dans la classification ISO
et baptisé passerelle ("bridge"),
- au moyen d'un logiciel situé au niveau 3 dans la classification ISO
et baptisé routeur,
- au moyen de convertisseurs de protocoles application par application
et couvrant les sept couches du modèle ISO.
La troisième solution permet d'utiliser n'importe quel protocole sur n'importe
quel réseau, mais elle exige le développement de m x n x (n-1)
logiciels convertisseurs de protocoles s'il y a m applications et n
réseaux différents; en outre, rien ne garantit que tous les
convertisseurs soient réalisables. Elle a donc été rejetée comme base de
l'interconnexion des réseaux locaux de l'U.C.L.
La première solution se caractérise par deux graves inconvénients :
- Elle n'est applicable, en pratique, qu'entre des réseaux de même
type. Interconnecter deux réseaux au niveau 2 revient, en effet, à les
considérer comme un réseau unique, ce qui n'a de sens que s'ils offrent
des services identiques. Ce n'est, en général, pas le cas s'ils sont de
types différents. L'environnement de l'U.C.L. comprenant des réseaux de
types différents (Ethernet, LocalTalk, Token-Ring, lignes série
synchrones, etc.), la première solution ne pouvait, en tout cas, pas être
généralisée.
Si l'on avait choisi le niveau 2, plutôt que le niveau 3, pour
l'interconnexion des réseaux, il aurait fallu choisir un seul type
physique de réseau, par exemple Ethernet ou Token-Ring, mais il aurait
été possible d'utiliser n'importe quel type de protocoles de plus haut
niveau (SNA, DECNET, DDN, etc.) sur cette interconnexion. Les machines
utilisant différentes familles de protocoles ne seraient néanmoins pas à
même de coopérer, à moins de réaliser des convertisseurs de protocoles
application par application, comme mentionné précédemment. Cette solution
aurait, en fait, été équivalente à un ensemble de réseaux indépendants
qui se seraient contentés de partager le même câble.
- La première solution implique, en outre, de gérer tout l'interréseau
de manière centralisée. Ceci limite la liberté des gestionnaires des
différents réseaux locaux et entraîne la distribution, dans tout
l'interréseau, de certains messages dont l'intérêt réel se limite aux
machines d'un des réseaux. Ceci surcharge inutilement les réseaux et les
machines.
- Enfin, dans une interconnexion de réseaux locaux au niveau 2, des
perturbations locales peuvent aisément se propager partout et provoquer
un effondrement total du réseau. Ce genre de phénomène catastrophique a
été observé dans des interconnexions de ce genre.
Ces trois arguments ont conduit à rejeter la solution de niveau 2
(passerelle). Les inconvénients qui précèdent n'existent pas lorsqu'on
interconnecte des réseaux par des routeurs de niveau 3.
- Avec des routeurs de niveau 3, on peut choisir librement le type de
support physique du réseau (de l'Ethernet à la ligne asynchrone, en
passant par le Token-Ring, la ligne synchrone à haute vitesse, les câbles
LocalTalk ou PhoneNet, etc.)
- Le routeur de niveau 3 n'implique qu'une gestion locale de chaque
réseau et des problèmes et perturbations qui s'y produisent. Les risques
de perturbation d'un réseau causée par un événement se produisant sur un
autre sont, sans être nuls, de plusieurs ordres de grandeur inférieurs à
ce qu'ils seraient avec des passerelles de niveau 2.
La deuxième solution (routeur de niveau 3) est donc la seule
techniquement raisonnable, ce qui a conduit l'U.C.L. à édicter la règle
suivante :
L'interconnexion des réseaux locaux dans le cadre de l'interréseau de
l'U.C.L. se fera, en règle générale, par routeurs situés au niveau 3 dans
le modèle ISO.
Ceci n'interdit pas d'interconnecter certains réseaux entre eux par des
passerelles de niveau 2, lorsqu'il existe des impératifs techniques en
faveur d'une telle solution et à condition que les gestionnaires des
réseaux concernés soient conscients des conséquences de leur choix, en
particulier de la nécessité de gérer collégialement les réseaux connectés
par passerelles. Chacun de ces ensembles de réseaux interconnectés par
passerelles est considéré comme un seul réseau par l'interréseau.
Choix des protocoles pour l'interréseau de l'U.C.L.
L'interconnexion de réseaux locaux par des routeurs de niveau 3 implique
le choix du ou des formats des paquets d'information qui pourront être
acheminés par ces routeurs. Ceci revient à choisir un ou des protocoles
situés au niveau 3 dans le modèle de référence ISO. Ceux-ci devront être
utilisés pour les communications entre interlocuteurs branchés à des
réseaux locaux distincts. Ceci signifie que les protocoles des couches 4
à 7 du modèle ISO utilisés par les services communs devront s'appuyer sur
celui ou ceux choisis pour le niveau 3. Ils devront donc appartenir à la
même famille.
Après avoir défini le modèle de référence en sept couches pour les
architectures de réseaux informatiques, l'ISO a commencé à standardiser
des protocoles concrétisant ce modèle. Il va de soi qu'à terme ce seront
des protocoles standardisés par l'ISO qui conviendront le mieux pour les
réseaux hétérogènes liant des équipements de provenances diverses, tels
que l'interréseau de l'U.C.L. Les protocoles ISO ne sont cependant pas
encore tous entièrement définis. De plus, ceux qui sont définis ne sont
pas encore suffisamment répandus pour pouvoir être utilisés de manière
opérationnelle dans l'interréseau de l'U.C.L. En règle générale, il
faudra attendre plusieurs années avant de pouvoir satisfaire les besoins
de l'U.C.L. au moyen des seuls protocoles ISO.
Il existe cependant une autre famille de protocoles, les
protocoles DDN (2), qui répondent bien aux
besoins de l'U.C.L. et représentent une solution intérimaire très
satisfaisante.
Ce choix offre les avantages suivants :
- L'utilisation de protocoles unifiés réduit très fort la complexité de
l'interconnexion des réseaux.
- Les protocoles DDN sont conçus pour l'interconnexion de réseaux
différents.
- Il existe des implantations des protocoles DDN pour la plupart des
ordinateurs et des systèmes d'exploitation.
- Les protocoles DDN ont été développés par des universités et des
centres de recherches avec le support du Département de la Défense
Américain : ils n'appartiennent à aucun constructeur et présentent donc
le même caractère d'impartialité que les protocoles ISO; certains de
ceux-ci s'inspirent d'ailleurs des protocoles DDN.
- Les protocoles DDN permettront ultérieurement la migration vers les
protocoles ISO. En effet, le Département de la Défense Américain,
promoteur des protocoles DDN, a l'intention de les remplacer, à terme,
par les protocoles ISO. Il devra donc résoudre les problèmes de
migration.
L'utilisation de protocoles unifiés ne doit pas être vue comme une
contrainte faisant obstacle à la liberté de chacun. En effet, l'usage
d'autres protocoles sur les réseaux constituant l'interréseau n'est pas
interdit, pour autant qu'ils puissent coexister avec DDN sur ce réseau.
L'usage d'autres protocoles resterait, néanmoins, limité :
- soit à un groupe de machines connectées au même réseau local;
- soit à un ensemble de machines de divers réseaux de l'interréseau, à
condition qu'un service "transporteur" (3) soit installé
ou que ces réseaux soient interconnectés indépendamment de l'interréseau
pour le protocole considéré. Certaines firmes offrent déjà des services
transporteurs pour certains protocoles (Fastpath de Kinetics pour les
protocoles AppleTalk sur Ethernet/DDN : logiciel KIP).
Les alternatives aux protocoles DDN sont des protocoles de constructeurs
et sont, en tant que tels, inacceptables car faussant le jeu de la
concurrence pour les marchés informatiques futurs.
Architecture de l'interréseau
L'architecture de l'interréseau est hiérarchisée. Elle comporte trois
classes de réseaux :
- classe 1 -
- Un réseau dorsal (Dorsale) qui fait partie de l'infrastructure
commune de l'Université et auquel ne sont connectés que des réseaux de
classe 2, appelés réseaux "côtes" et certaines machines d'intérêt
général, telles que le Centre de Calcul et le Centre de Tri du Courrier
Electronique. Les équipements de connexion des réseaux côtes au dorsal
font également partie de l'infrastructure commune de l'Université.
- classe 2 -
- Des réseaux côtes, tels que Levant, Sciences 1, CALC, Cochise, Halles,
Goria, Croix du Sud et LeW, connectés au dorsal et desservant des
quartiers.
- classe 3 -
- Des réseaux départementaux, d'unité, etc., connectés aux côtes, soit
directement, soit via un autre réseau qui devrait, en général, dépendre
de la même entité ou d'une entité englobante (par exemple, le réseau
associé à un projet peut être connecté au réseau d'Unité, lui-même
connecté à un réseau de département ou peut être connecté au réseau côte,
ou toute solution intermédiaire).
Ces réseaux peuvent être de n'importe quel type (Ethernet, Token-Ring,
LocalTalk...) pourvu qu'ils supportent les protocoles DDN, c'est-à-dire
qu'ils permettent le passage de paquets DDN-IP (4).
Les réseaux sont connectés entre eux par des routeurs DDN-IP. Chaque
réseau peut être divisé en tronçons par des passerelles de niveau 2 (MAC
Level Bridge) afin d'augmenter la longueur réalisable ou afin de confiner
une partie du trafic dans une partie du réseau. L'ensemble des tronçons
d'un réseau est géré comme un tout.
La structure hiérarchique de l'interréseau n'interdit pas l'adjonction
d'autres liaisons entre les sous-réseaux, là où le trafic le justifie.
Dans le futur, l'interréseau devra migrer vers les protocoles ISO,
lorsque ceux-ci deviendront disponibles en pratique. Pendant la
transition, il supportera les deux familles de protocoles, DDN et ISO.
Première phase du projet MERCURE
Le Conseil d'Administration de l'U.C.L. a approuvé le 21 juin 1989 la
première phase de réalisation du projet MERCURE.
Celle-ci comporte l'interconnexion, via un réseau dorsal provisoire, d'un
certain nombre de réseaux locaux existants ou en projet, promus à la
fonction de réseaux côtes. Cette première phase comporte, en outre, la
mise en service d'un système global de courrier électronique pour
l'Université et la mise en place du mode de gestion de l'interréseau et
du service responsable, notamment, de l'infrastructure commune et des
services communs (courrier électronique, gestion répartie des
imprimantes, etc.). La mise en service de cette première phase est prévue
par étapes au cours du dernier trimestre 1989.
Interconnexion des réseaux locaux : l'interréseau
Nature et localisation du réseau Dorsale de la première phase
A terme, le réseau Dorsale (adresse : 130.104.1.0) devra être un réseau
local rapide tel que FDDI (réseau en fibre optique à 100 Mbps). Ce genre
de réseau ne peut cependant pas s'envisager aujourd'hui dans des
conditions économiquement réalistes pour une réalisation opérationnelle.
Le réseau Dorsale est donc réalisé en Ethernet, le marché étant plus
ouvert pour ce type de réseau. Ce réseau sera utilisé pendant deux ans,
c'est-à-dire jusqu'en août 1991. A ce moment-là, sur base de l'évolution
du trafic et de la technologie, on pourra décider son remplacement par un
autre type de réseau mieux adapté (FDDI, par exemple), ou de continuer à
l'utiliser pour une durée à déterminer.
Ce dorsal en Ethernet est très court et ne dessert que le bâtiment
Archimède, où aboutissent actuellement les réseaux côtes, et le bâtiment
Pythagore où est localisé le Centre de Calcul et où sera installée la
machine servant de Centre de tri du Courrier Electronique.
Connexion des réseaux côtes
Les réseaux côtes seront raccordés au réseau Dorsale dans un local situé
dans les caves du bâtiment Archimède via un routeur multiréseaux et
multiprotocoles, utilisé pour la première phase avec le protocole DDN-IP.
Les réseaux côtes impliqués dans cette première phase sont les suivants :
Adresse Nom responsable
130.104.02.0 Levant H. Broze
130.104.03.0 Sciences 1 Fr. Somers
130.104.04.0 Cochise J.P. Lemaître
130.104.05.0 LeW B. Debande
130.104.06.0 Halles Fr. Donckels
130.104.07.0 Croix du Sud S. Roumieux
130.104.08.0 Goria D. Dieudonné
130.104.09.0 Esope B. Paris
130.104.10.0 Compas J.P. Kuypers
130.104.64.0 CALC A. Debroux
Le routeur, de type "Wellfleet Link Node", contient six interfaces
Ethernet (pour les réseaux Dorsale, Levant, Sciences 1, Halles, Cochise et
Croix du Sud), une interface Token-Ring 16 Mbps (pour le réseau CALC) et
deux interfaces série synchrone V.35, à 64 kbps, connectées
respectivement à une ligne RTT louée vers Louvain-en-Woluwe et à une
ligne privée U.C.L. en site propre vers le réseau Goria. Pour cette
dernière ligne, il est fait usage d'une paire de modems rapides en bande
de base.
Deux autres routeurs "Wellfleet Link Node" sont installés à Woluwé et sur
le site "Goria". Ils ne sont dotés que d'une interface Ethernet et d'une
interface V.35.
Pour la connexion des réseaux Sciences 1 et Halles, des liaisons en fibre
optique sont utilisées. Ces fibres sont branchées d'une part au routeur
du bâtiment Archimède et d'autre part au réseau côte. Ces fibres optiques
pourront ultérieurement être intégrées dans le futur dorsal FDDI.
Les réseaux Dorsale, Levant, Cochise et Croix du Sud sont connectés
directement au Wellfleet. A cet effet Cochise et Croix du Sud ont été
prolongés respectivement à partir des bâtiments Lavoisier et Kellner, où
sont placées des passerelles de niveau 2, jouant ici un rôle de répéteur.
Le Token-Ring CALC sera (en 1990) également connecté directement au
routeur Wellfleet du bâtiment Archimède.
Prospective : Ce que pourrait être un futur réseau Dorsale en FDDI
(fibres optiques)
Le dorsal en fibres optiques pourrait partir du bâtiment de Hemptinne, où
un routeur devrait être installé pour connecter les Ethernet locaux. Il
rejoindrait, via les fibres optiques existantes, le bâtiment Archimède où
il réutiliserait le routeur Wellfleet du réseau Dorsale provisoire
Ethernet. Il continuerait ensuite vers les Halles, où un autre routeur
desservirait les réseaux du centre ville, puis rejoindrait un routeur
situé dans le quartier des Sciences Humaines, à l'autre bout de la dalle
du centre ville, pour enfin remonter vers un dernier routeur dans le
quartier des sports (Hocaille).
Le réseau de l'U.C.L., en juin 1989 (les réseaux de classe 3 ne sont pas
représentés)
Le réseau de l'U.C.L., après mise en oeuvre de la première phase du
projet MERCURE (les réseaux de classe 3 ne sont pas représentés)
(les passerelles représentées servent à permettre la mise en oeuvre de
réseaux côtes longs : elles servent de répéteurs; leur fonction de
filtrage est accessoire.)
Organisation de la gestion de l'interréseau
Responsabilité de la gestion des réseaux
La responsabilité de la gestion des réseaux est décentralisée. Les tâches de
gestion sont réparties entre le Service des Réseaux
d'Information (SRI), les gestionnaires des réseaux côtes et ceux des
réseaux de classe 3. Le rôle principal est joué par les gestionnaires de
réseaux côtes épaulés par le SRI. Les problèmes impliquant plus d'un réseau
côte sont discutés au groupe ILAN, qui est un groupe de
travail opérant en étroite collaboration avec la sous-commission Prospectives
Techniques de la Commission de l'Informatique (5). Les
responsables des réseaux côtes et du SRI sont membres du groupe ILAN. Les conflits sont tranchés par le président
de la Commission de l'Informatique ou par la personne à laquelle il a
délégué cette responsabilité.
Le travail de gestion d'un réseau, et plus particulièrement d'un
réseau côte, représente une charge qui doit être prise en compte dans la
décision d'implanter un réseau : il faut dégager des ressources
financières pour l'installation et l'évolution du réseau mais aussi
des ressources humaines pour assurer sa gestion. Pour garantir le
bon fonctionnement de l'interréseau de l'U.C.L., on n'attribue de numéro
de réseau que dans la mesure où le nom du responsable est connu et, pour
les réseaux côtes, dans la mesure où ce dernier ou un de ses subordonnés
peut consacrer le temps voulu à la gestion du réseau. Ce temps est estimé
à 0,4 ETP (Equivalent Temps Plein). Pour de grands réseaux côtes, comme
LeW, ce temps sera sans doute plus important. Il faut régulièrement
vérifier si le personnel affecté à la gestion de chaque réseau côte est
adéquat, en fonction de la charge réelle de cette tâche.
Les réseaux côtes
Le gestionnaire d'un réseau côte est responsable du bon fonctionnement de
son réseau.
- Le gestionnaire de réseau côte organise un
comité des utilisateurs de son réseau. Il accepte la connexion à
son réseau de machines clientes et de réseaux de classe 3, après s'être
assuré que ceux-ci ne perturberont pas le bon fonctionnement du réseau
côte et que leurs promoteurs acceptent de gérer leur équipement de
manière compatible avec le fonctionnement harmonieux du réseau et
acceptent de couvrir le coût du raccordement et une participation au coût
d'exploitation du réseau côte. Cette participation sera fixée
conjointement par le responsable et les utilisateurs au sein du comité
des utilisateurs du réseau. Le gestionnaire de réseau côte transmet aux
gestionnaires des machines clientes et des réseaux de classe trois
connectés à son réseau les directives nécessaires à la coexistence
harmonieuse de ceux-ci au sein du réseau :
- adaptations de certains paramètres de configuration d'applications
réparties,
- nombre de serveurs pour un service particulier et priorité éventuelle
entre ceux-ci,
- mise à jour des informations de routage,
- etc.
- C'est au gestionnaire de réseau côte que s'adressent ceux qui veulent
connecter un réseau de classe 3 ou une machine, afin d'obtenir un avis
technique sur la manière de se connecter, le type d'équipement et/ou de
logiciel nécessaire, etc. Le gestionnaire de réseau côte peut demander
l'assistance du Service des Réseaux d'Information pour leur répondre. Il
veille cependant à acquérir une certaine compétence dans
le domaine des réseaux, en particulier sur les protocoles DDN (6), les outils d'analyse de trafic dont il dispose et les
applications réparties utilisées sur son réseau.
- Il est responsable de la maintenance de son réseau :
- contrôle de l'importance et de la nature du trafic, avant et après
nouvelles connexions et avec une régularité suffisante pour pouvoir
suivre l'évolution de l'utilisation du réseau, en particulier lorsqu'un
comportement anormal est détecté;
- isolation et diagnostic des pannes ou comportements anormaux;
- planification et mise en oeuvre de l'évolution des logiciels réseau
et de la structure du réseau.
Dans ces tâches, il peut se faire aider par le SRI.
Les réseaux de troisième niveau et les machines connectées aux réseaux
"côtes"
Tout équipement, machine ou réseau, connecté à un réseau côte doit avoir
un gestionnaire responsable qui servira d'interlocuteur au gestionnaire
du réseau côte en cas de problème. Ce responsable préviendra le
gestionnaire de réseau côte de la nature et du moment où se produira
toute manipulation pouvant avoir des répercussions sur le réseau côte
(connexion de la machine ou du réseau de classe 3, changement de logiciel
ou de configuration, etc.).
Le routeur DDN-IP entre le réseau côte et le réseau de classe 3 est de la
responsabilité du gestionnaire du réseau de classe 3. Les coûts d'achat
et d'exploitation de ce routeur sont à charge de l'entité propriétaire du
réseau de classe 3.
Le gestionnaire du réseau de classe 3 gère son réseau et décide des
conditions de connexion d'autres réseaux de classe 3 au sien.
Le réseau dorsal et le Service des Réseaux d'Information
- Le Service des Réseaux d'Information (SRI) est responsable de la
gestion du réseau dorsal, y compris des routeurs DDN-IP vers les réseaux
côtes et des divers équipements utilisés pour connecter le réseau côte au
dorsal (tronçons à fibres optiques, à ligne synchrone, etc.).
Il contrôle les contributions de chaque réseau côte à la charge du dorsal
et prend les mesures nécessaires en cas de déséquilibre gênant.
- Il gère les services globaux basés sur des réseaux à l'Université
(courrier électronique, accès aux machines distantes, transfert de
fichiers, etc.) : mise en oeuvre de ces services, organisation de la
collaboration des différents gestionnaires pour leur exploitation, aide à
l'implantation de ces services sur les types de machines reconnues
d'intérêt stratégique pour l'Université, etc.
Il gère les machines communes qui ont la communication comme fonction
principale.
Il maintient les logiciels correspondant aux services globaux sur les
autres machines communes, en collaboration avec les responsables de
celles-ci.
- Il assure la consultance au profit des gestionnaires de réseaux côtes
mais pas l'exploitation de ceux-ci. Il conseille, à la demande des
gestionnaires de réseaux côtes, les gestionnaires de réseaux de classe 3.
Il conseille, à leur demande, les candidats acheteurs de machines ou de
réseaux au sujet des logiciels permettant, sur ces machines, d'accéder
aux services communs, ou leur déconseille, le cas échéant, l'achat de
certains réseaux ou machines.
Il évalue, en matière de réseaux, les nouveaux produits intéressant
l'Université ou un ensemble raisonnable de ses membres, afin de pouvoir
en conseiller ou déconseiller l'acquisition et en guider la mise en
oeuvre.
- A la demande de la Commission de l'Informatique, il installe, adapte,
ou, si indispensable, développe les logiciels de communication d'intérêt
général sur les types de machines d'intérêt stratégique pour
l'université.
Il prépare l'évolution des réseaux et des services globaux (en
particulier migration vers OSI).
Pendant la mise en route de la première phase du projet MERCURE, la
mission du Service des Réseaux d'Information est remplie par deux
informaticiens universitaires expérimentés, J.P. Kuypers
et A. Fontaine
qui sont appuyés par diverses autres personnes. L'effectif opérationnel
nécessaire est actuellement estimé à trois personnes et sera défini début
1990. Il devra être revu en fonction de l'évolution des besoins.
Après 24 mois, il est prévu d'évaluer l'efficacité de l'organisation de
la gestion du réseau, en particulier du SRI, et, si besoin, d'adapter
cette organisation. Il faudra aussi vérifier l'adéquation du personnel
affecté à la gestion des réseaux côtes à la charge représentée par
celle-ci.
Coordination du choix des adresses de machines
sur l'interréseau U.C.L. - centralisation de l'attribution des
identificateurs des réseaux locaux
Dans l'interconnexion d'un ensemble de réseaux différents par un routeur
de niveau 3 basé sur les protocoles DDN, chaque machine est identifiée
par un numéro appelé adresse DDN-IP. Ces adresses doivent être uniques
dans l'interréseau et leur attribution doit donc se faire de manière
concertée.
Il existe plusieurs formats d'adresses "DDN-IP". Tous comportent quatre
octets. Celui qui convient à l'U.C.L., vu le nombre de machines qu'on
envisage d'interconnecter (entre 254 et 64.516), est le format dit de
"type B". Dans ce format, le numéro du réseau comporte deux octets. Il
reste donc deux octets pour identifier les machines de l'U.C.L.
Le "Stanford Research Institute Network Information Center" (SRI-NIC) est
un organisme central attribuant, au niveau mondial, des numéros de réseau
DDN-IP aux organismes qui le demandent afin de garantir l'unicité de ces
numéros. L'objectif est d'éviter qu'en connectant un jour deux réseaux on
s'aperçoive qu'ils ont le même numéro. Un numéro de "type B" a été
demandé par l'U.C.L. pour son interréseau : c'est le 130.104.0.0.
Grâce à cette démarche, il sera possible de connecter, si on le désire un
jour, l'interréseau de l'U.C.L. à un autre réseau utilisant les mêmes
protocoles sans risque de conflit d'adresses.
L'interréseau est divisé en, au maximum, 254 sous-réseaux de, au maximum,
254 machines chacun. Chaque réseau local est considéré comme un sous-réseau.
Pour garantir l'unicité des adresses "DDN-IP" des différents ordinateurs les
numéros de sous-réseaux sont attribués de manière centralisée et on laisse
au gestionnaire de chaque réseau local le soin d'attribuer les adresses des
machines individuelles dans le sous-réseau formé par son réseau local.
Les numéros de sous-réseaux sont attribués aux réseaux locaux à connecter
à l'interréseau par
M. Lobelle,
président du Groupe ILAN, sur mandat de la Commission de
l'Informatique.
Sans précaution de ce genre, des conflits seraient inévitables : les
fabricants installant des réseaux donnent toujours, par défaut, le même
numéro à tous les réseaux qu'ils installent.
Un service global de courrier électronique pour l'U.C.L.
Les besoins
Les besoins de l'U.C.L. en matière de courrier électronique sont de deux types :
- Possibilité d'échanger du courrier avec des correspondants
extérieurs à l'U.C.L. à travers les réseaux existants ou à venir :
EARN/BITNET, EUNET, etc.
- Possibilité d'échanger du courrier entre membres de
l'U.C.L. Dans ce cas il est important que chacun dispose, pour son
courrier, du niveau de qualité auquel il est habitué, tant pour le contenu
du courrier (accents) que pour l'interface du système de courrier électronique.
Il est tout aussi important que toute personne ayant accès à un système
informatique puisse communiquer avec n'importe quelle autre au sein de
l'université, quels que soient les systèmes dont ils disposent (UNIX,
VM/CMS, VMS, PC, Macintosh, etc.).
Ces deux classes de besoins devraient être satisfaites par le même
système de courrier électronique. Dans ce courrier, il est souhaitable de
pouvoir envoyer des fichiers de grande taille (20 à 30 Moctets) et/ou de
contenu quelconque (fichiers de traitement de texte, données, sources
FORTRAN, etc.), éventuellement par la mise en oeuvre d'un service de
découpage (à partir des messages de 20 Koctets) et d'encodage . Pour les
destinataires extérieurs à l'Université, on est cependant tributaire des
capacités de décodage et de réassemblage dont ils disposent.
Ces deux classes de besoins doivent être étendues, en réception, à tout le
personnel de l'Université par conversion automatique vers le courrier-papier
pour les personnes ne disposant pas de boîte aux lettres électronique.
Architecture d'un système de courrier électronique
Un système de courrier électronique est, selon le modèle adopté par les
normes internationales (X.400/88), un logiciel d'application réparti
asynchrone qui achemine, en différé, des messages entre ses utilisateurs.
Ces messages sont constitués d'une enveloppe et d'un contenu. Comme pour
du courrier-papier, l'enveloppe sert à inscrire l'adresse du
destinataire, l'adresse de l'expéditeur et diverses informations
destinées au système d'acheminement des messages. Le contenu n'est
normalement pas touché par le système d'acheminement des messages (sauf
si l'utilisateur a explicitement demandé une conversion). L'organisation
interne du contenu est appelée architecture de contenu. Il
suffit donc qu'un couple de destinataires s'entendent sur l'architecture
de contenu, indépendamment du système d'acheminement des messages, pour
qu'ils puissent échanger des informations particulières.
Un système de courrier électronique est composé de quatre types d'agents
(qui sont des programmes) coopérant entre eux :
- des agents de transfert de messages (MTA), qui, ensemble, forment le
système d'acheminement des messages;
- éventuellement, des agents d'interface (AU : Access Unit) avec
d'autres systèmes d'acheminement d'informations, tels que TELEX, TELEFAX,
courrier-papier, etc.);
- des agents archiveurs (MS : Message Store) qui gèrent les boîtes aux
lettres électroniques et archivent les messages reçus pour les
utilisateurs;
- des agents utilisateurs (UA) qui sont des programmes qui assistent
l'utilisateur dans la préparation, l'adressage, l'envoi, la réception, la
lecture et l'archivage de messages. Ce n'est qu'à travers son UA que
l'utilisateur voit le système de courrier électronique.
Ces deux dernières fonctions peuvent être cumulées par un même programme.
Architecture du système de courrier électronique de l'U.C.L.
Traduction des besoins en termes des composants de l'architecture d'un
système de courrier électronique et contraintes techniques
Pour satisfaire les besoins exprimés ci-dessus, il faut installer un ensemble de
MTA interconnectables entre eux (pas nécessairement deux à deux) et avec ceux
des systèmes extérieurs tels que EARN/BITNET et EUNET et connectés à ces
systèmes.
Il faut installer des MS (gestionnaires de boîtes aux lettres) accessibles aux
UA des utilisateurs quand ceux-ci le souhaitent, et à tout moment par un MTA.
Il faudra de plus rendre possible pour chaque membre de la communauté
l'acquisition d'un UA, compatible avec ces MS, qui
- réponde à ses critères de convivialité,
- offre les services normaux d'un système de courrier électronique
(préparation de messages, y compris inclusion de fichiers de n'importe
quel type avec la description de leur type, adressage, envoi, réception,
sélection dans le courrier reçu, lecture, archivage).
Il faut aussi choisir une architecture de contenu qui permette d'envoyer
les informations souhaitées, soit compréhensible par tous les UA de
l'U.C.L., puisse passer à travers les MTA de l'U.C.L. et puisse être
envoyée aux correspondants extérieurs. Ceci est actuellement impossible,
car les réseaux extérieurs ne laissent passer avec certitude que les
petits messages (pas plus de quelques dizaines de milliers de caractères)
limités aux caractères ASCII (7 bits) imprimables.
Pour le système d'acheminement des messages, il existe deux
spécifications indépendantes des constructeurs : X.400/88 du CCITT et de
l'ISO et RFC822 du DDN. A terme, il faudra migrer vers X.400/88, mais
actuellement, il existe déjà à l'U.C.L. une ossature basée sur RFC822 et
cette spécification est également utilisée dans les réseaux EARN/BITNET
et EUNET. Aussi bien X.400 que RFC822 peuvent être supportés par un
réseau DDN-IP, comme celui de l'U.C.L., et les possibilités de X.400/88
sont nettement supérieures à celles des systèmes basés sur RFC822. Tous
les constructeurs travaillent actuellement à des produits basés sur
X.400/88 et ceux-ci déferleront probablement sur le marché vers la fin de
1990 (7). A ce moment, le monde basculera sans doute de
RFC822 vers X.400/88. Les implantations X.400 disponibles actuellement
sont souvent basés sur X.400/84, une norme expérimentale provisoire, ou
sont des hybrides entre X.400/84 et X.400/88.
L'infrastructure proposée d'acheminement et d'archivage des messages de
1989 à 1991
Comme il ne semble pas raisonnable d'attendre 1991 pour mettre un système
de courrier électronique en service, l'U.C.L. a décidé d'étendre, à
moindres frais, le système existant basé sur RFC822 à l'ensemble de
l'Université. Dans deux ans, on doublera ce système d'un système basé sur
X.400/88 mais on installera une passerelle entre les deux systèmes dès
que possible afin de préparer cette migration. Lorsque le système
X.400/88 aura été mis en service, il sera possible à ceux qui n'ont pas
besoin du nouveau service de conserver leur ancien UA.
Chaque machine contenant un MTA contiendra aussi les MS des utilisateurs
qui y sont rattachés. Les MTA échangeront des messages de format RFC822.
Il y aura deux types de MTA, chacun d'eux flanqué de MS et acceptant des
UA clients locaux (sur la même machine) ou distants (p.ex., sur des PC ou
des Macintosh).
Les MTA du premier type, appelés MTA principaux, feront partie
de l'infrastructure commune de l'Université. Ils seront gérés par le SRI.
Ces MTA principaux seront destinés au routage du courrier
électronique, à la connexion aux réseaux extérieurs et au rattachement
d'UA appartenant à des entités ne possédant pas de MTA local.
Les MTA du second type, appelés MTA locaux, appartiendront à des
entités (unités, départements), serviront au rattachement des UA des
membres de l'entité et seront configurés de sorte que leur gestion puisse
être réduite à sa plus simple expression. Ces MTA locaux pourront
envoyer tout courrier non local à un seul MTA principal qui se
chargera du routage de celui-ci mais ils pourront connaître d'autres MTA;
l'effet est le même pour les UA rattachés.
Dans la première phase du projet MERCURE, on utilisera comme MTA
principaux le routeur de courrier EARN du Centre de Calcul et un
routeur UNIX (ou éventuellement plusieurs si un grand nombre d'entités ne
s'équipe que de UA). Une machine UNIX sera acquise pour y placer ce MTA
principal. Cette machine devrait avoir accès à EUNET via DCS.
Dès que possible, il faudra installer au moins un MTA
principal X.400/88 et une passerelle vers RFC822 pour rendre ce
service possible pour ceux qui en ont besoin.
Les UA
L'U.C.L. doit disposer dans un premier temps d'UA pour les systèmes
Mac OS, UNIX, OS/2, MS-DOS, VM/CMS et VAX VMS.
Sur VM/CMS, UNIX et MS-DOS, il existe des logiciels qui peuvent servir
d'UA. Cependant ils ne sont prévus que pour des contenus limités à du texte
non structuré en ASCII (7 bits). On pourrait assez facilement modifier la
plupart de ces UA pour leur permettre d'accepter n'importe quel caractère
(y compris caractères accentués et inclusion de fichiers quelconques).
Ceci permettrait d'avoir un groupe fermé d'utilisateurs disposant d'un meilleur
service (accents, transfert de fichiers quelconques) mais les messages sortant
de ce groupe devraient être traduits vers la forme plus simple.
Pour les Macintosh, des UA compatibles avec l'infrastructure d'acheminement
de messages proposée ci-dessus seront prochainement disponibles.
Coordination du choix des noms identifiant les
membres de la communauté universitaire pour le courrier électronique
Les deux principaux réseaux de messagerie électronique utilisés par les
institutions de recherche en Belgique, EARN et EUNET, ont décidé
d'harmoniser les noms des utilisateurs selon la "norme" DDN RFC 822, en
attendant la possibilité d'utiliser la norme X.400 du CCITT (Comité
Consultatif International pour la Téléphonie et la Télégraphie).
Ainsi, les personnes auront un nom du type
désignation_interne.institution.ac.be
Ces noms doivent être sans accents.
L'institution "Université Catholique de Louvain" est désignée par le
sigle "ucl".
La règle suivante est utilisée afin de coordonner les choix des
désignations internes de personnes :
En attendant le mise en oeuvre des noms X.400, les membres de l'U.C.L.
seront connus à l'extérieur, pour la messagerie électronique, sous des
noms de type :
identificateur_personnel@entité.ucl.ac.be
L'entité (unité, service) est l'élément de la structure U.C.L. de plus
bas niveau repris dans la liste d'adresses (c'est-à-dire plutôt unité ou
département que faculté); s'il y a plusieurs entités, on prendra la
première citée. Les personnes rattachées au cadre de plusieurs entités
peuvent aussi se faire connaître sous plusieurs pseudonymes correspondant
à ces entités.
A partir de la prochaine édition de la liste d'adresses U.C.L., les désignations
de courrier électronique des gens qui y ont accès seront mentionnées.
Cette structure pour les noms permet d'identifier aisément les personnes
et décentralise le choix des identificateurs au niveau des entités.
Cette règle n'interdit évidemment pas d'utiliser, au niveau des
interfaces utilisateur, des adresses plus conviviales.
Le groupe ILAN
Le groupe ILAN (pour "Interconnected Local Area Networks") s'est formé
spontanément fin 1987 pour discuter les problèmes posés par la gestion
des différents réseaux de l'U.C.L., par leur développement et par leur
interconnexion. Il regroupe des personnes soucieuses de ces problèmes et
possédant une compétence technique dans le domaine des réseaux
d'ordinateurs en général et des réseaux utilisés à l'U.C.L. en
particulier. Il est ouvert aux personnes répondant à ces conditions.
L'objectif du groupe a été présenté à la Commission de l'Informatique qui
l'a approuvé et a souhaité son extension pour que les diverses entités
concernées y soient, autant que possible, représentées et pour que le
groupe coopère avec la sous-commission Perspectives Techniques de la
Commission de l'Informatique.
Le groupe a produit le document qui sert de base à la définition de la
politique générale en matière de réseaux de l'U.C.L. Ce
document a été
approuvé par la Commission de l'Informatique et par le Conseil Académique
du 3 octobre 1988.
Le projet MERCURE est un résultat des travaux du groupe.
Le présent document, dont la version initiale a été approuvée par la
Commission de l'Informatique du 14 juillet 1989, synthétise ce projet en
se basant sur divers documents de travail du groupe.
Plusieurs documents
de travail ont été rédigés dans le cadre du groupe
ILAN. Ces documents ne sont en général pas diffusés en dehors du groupe
au nom de celui-ci pour éviter que des opinions personnelles qui y
seraient exprimées ne soient confondues avec l'opinion du groupe. Seuls
sont diffusés les documents approuvés pour diffusion par le groupe. Les
autres portent l'indication "diffusion restreinte".
Les membres du groupe et leur réseau ou entité de rattachement sont
actuellement : MM. S. Roumieux (réseau Croix du Sud), H. Broze (réseaux
Levant et FSAETDS), B. Debande (réseau LeW), A. Debroux (réseau CALC),
Mme M.Fr. Declerfayt (réseaux INFO), MM. D. Dieudonné (réseau Goria), Fr.
Donckels (réseau Halles), A. Fontaine (SRI), J.P. Kuypers (SRI), J.P.
Lemaître (réseau Cochise), M. Lobelle (président du groupe ILAN), E.
Milgrom (président de la Sous-Commision de Prospectives Techniques de la
Commission de l'Informatique), B. Paris (PSP) et Fr. Somers (réseau
Sciences 1).
Notes :
- Il est recommandé aux personnes qui effectuent des
choix en matière de réseaux locaux de tenir compte des contraintes de
cette interconnexion, dans la mesure où celles-ci ne sont pas contraires
à leurs objectifs prioritaires. Si des choix restreignant les
possibilités d'interconnexion leur apparaissaient préférables, la
Commission de l'Informatique devrait en être préalablement informée.
- parfois appelés TCP/IP ou DARPA
- c'est-à-dire un service qui achemine des messages de
format non-DDN en les emballant dans des paquets DDN-IP (4).
- DDN-IP est le protocole de niveau 3 de la famille de
protocoles DDN.
- Le groupe ILAN est présenté dans la
dixième section de ce document.
- Il est recommandé de posséder et d'avoir lu le livre
"Internetworking with TCP/IP" de D. Comer, Prentice Hall, 1988.
- Les autres protocoles ISO ne se populariseront sans
doute que plus tard.
Page : UCL
| SRI
| Interréseau UCL
| Pointeurs utiles.
6 juillet 1996.
Responsable : Jean-Pierre
Kuypers