Le
modèle OSI
1 - Introduction
2 - Les
différentes couches du modèle
2.1 - Les 7 couches
2.2 - La couche physique
2.3 - La
couche liaison de données
2.4 - La couche réseau
2.5 - Couche transport
2.6 - La couche session
2.7 - La couche
présentation
2.8 - La couche
application
3 - Transmission
de données au travers du modèle OSI
4 - Critique
du modèle OSI
4.1 - Ce
n'était pas le bon moment
4.2 - Ce
n'était pas la bonne technologie
4.3 - Ce
n'était pas la bonne implémentation
4.4 - Ce
n'était pas la bonne politique
5 - L'avenir d'OSI
6 - Discussion
autour de la documentation
7 - Suivi du document
Les constructeurs informatiques ont proposé des
architectures réseaux propres à leurs équipements. Par exemple, IBM a proposé
SNA, DEC a proposé DNA... Ces architectures ont toutes le même défaut : du
fait de leur caractère propriétaire, il n'est pas facile des les
interconnecter, à moins d'un accord entre constructeurs. Aussi, pour éviter la
multiplication des solutions d'interconnexion d'architectures hétérogènes,
l'ISO (International Standards Organisation), organisme dépendant de l'ONU et
composé de 140 organismes nationaux de normalisation, a développé un modèle de
référence appelé modèle OSI (Open Systems Interconnection). Ce modèle décrit les concepts utilisés et
la démarche suivie pour normaliser l'interconnexion de systèmes ouverts (un
réseau est composé de systèmes ouverts lorsque la modification, l'adjonction ou
la suppression d'un de ces systèmes ne modifie pas le comportement global du
réseau).
Au moment de la conception de ce modèle, la prise en compte de l'hétérogénéité
des équipements était fondamentale. En effet, ce modèle devait permettre
l'interconnexion avec des systèmes hétérogènes pour des raisons historiques et
économiques. Il ne devait en outre pas favoriser un fournisseur particulier.
Enfin, il devait permettre de s'adapter à l'évolution des flux d'informations à
traiter sans remettre en cause les investissements antérieurs. Cette prise en
compte de l'hétérogénéité nécessite donc l'adoption de règles communes de
communication et de coopération entre les équipements, c'est à dire que ce
modèle devait logiquement mener à une normalisation internationale des
protocoles.
Le modèle OSI n'est pas une véritable architecture de réseau, car il ne précise
pas réellement les services et les protocoles à utiliser pour chaque couche. Il
décrit plutôt ce que doivent faire les couches. Néanmoins, l'ISO a écrit ses
propres normes pour chaque couche, et ceci de manière indépendante au modèle,
i.e. comme le fait tout constructeur.
Les premiers travaux portant sur le modèle OSI datent de 1977. Ils ont été
basés sur l'expérience acquise en matière de grands réseaux et de réseaux
privés plus petits ; le modèle devait en effet être valable pour tous les
types de réseaux. En 1978, l'ISO propose ce modèle sous la norme ISO IS7498. En
1984, 12 constructeurs européens, rejoints en 1985 par les grands constructeurs
américains, adoptent le standard.
2.
Les
différentes couches du modèle
Le modèle
OSI comporte 7 couches :
Les principes qui ont conduit à ces 7 couches sont les suivants :
- une couche doit être créée lorsqu'un nouveau niveau d'abstraction est
nécessaire,
- chaque couche a des fonctions bien définies,
- les fonctions de chaque couche doivent être choisies dans l'objectif de la
normalisation internationale des protocoles,
- les frontières entre couches doivent être choisies de manière à minimiser le
flux d'information aux interfaces,
- le nombre de couches doit être tel qu'il n'y ait pas cohabitation de fonctions
très différentes au sein d'une même couche et que l'architecture ne soit pas
trop difficile à maîtriser.
Les couches basses (1, 2, 3 et 4)
sont nécessaires à l'acheminement des informations entre les extrémités
concernées et dépendent du support physique. Les couches hautes (5, 6 et 7)
sont responsables du traitement de l'information relative à la gestion des
échanges entre systèmes informatiques. Par ailleurs, les couches 1 à 3
interviennent entre machines voisines, et non entre les machines d'extrémité
qui peuvent être séparées par plusieurs routeurs. Les couches 4 à 7 sont au
contraire des couches qui n'interviennent qu'entre hôtes distants.
La couche physique s'occupe
de la transmission des bits de façon brute sur un canal de communication. Cette
couche doit garantir la parfaite transmission des données (un bit 1 envoyé doit
bien être reçu comme bit valant 1). Concrètement, cette couche doit normaliser
les caractéristiques électriques (un bit 1 doit être représenté par une tension
de 5 V, par exemple), les caractéristiques mécaniques (forme des connecteurs,
de la topologie...), les caractéristiques fonctionnelles des circuits de
données et les procédures d'établissement, de maintien et de libération du
circuit de données.
L'unité d'information typique de cette couche est le bit, représenté par une
certaine différence de potentiel.
2.3 - La couche liaison de données
Son rôle est un rôle de
"liant" : elle va transformer la couche physique en une liaison
a priori exempte d'erreurs de transmission pour la couche réseau. Elle
fractionne les données d'entrée de l'émetteur en trames, transmet ces trames en
séquence et gère les trames d'acquittement renvoyées par le récepteur.
Rappelons que pour la couche physique, les données n'ont aucune signification
particulière. La couche liaison de données doit donc être capable de
reconnaître les frontières des trames. Cela peut poser quelques problèmes,
puisque les séquences de bits utilisées pour cette reconnaissance peuvent
apparaître dans les données.
La couche liaison de données doit être capable de renvoyer une trame lorsqu'il
y a eu un problème sur la ligne de transmission. De manière générale, un rôle
important de cette couche est la détection et la correction d'erreurs
intervenues sur la couche physique. Cette couche intègre également une fonction
de contrôle de flux pour éviter l'engorgement du récepteur.
L'unité d'information de la couche liaison de données est la trame qui est
composées de quelques centaines à quelques milliers d'octets
maximum.
C'est la couche qui permet de
gérer le sous-réseau, i.e. le routage des paquets sur
ce sous-réseau et l'interconnexion des différents sous-réseaux entre eux. Au moment de sa conception, il faut
bien déterminer le mécanisme de routage et de calcul des tables de routage
(tables statiques ou dynamiques...).
La couche réseau contrôle également l'engorgement du sous-réseau.
On peut également y intégrer des fonctions de comptabilité pour la facturation
au volume, mais cela peut être délicat.
L'unité d'information de la couche réseau est le paquet.
Cette couche est responsable
du bon acheminement des messages complets au destinataire. Le rôle principal de
la couche transport est de prendre les messages de la couche session, de les
découper s'il le faut en unités plus petites et de les passer à la couche
réseau, tout en s'assurant que les morceaux arrivent correctement de l'autre
côté. Cette couche effectue donc aussi le réassemblage du message à la réception
des morceaux.
Cette couche est également responsable de l'optimisation des ressources du
réseau : en toute rigueur, la couche transport crée une connexion réseau
par connexion de transport requise par la couche session, mais cette couche est
capable de créer plusieurs connexions réseau par processus de la couche session
pour répartir les données, par exemple pour améliorer le débit. A l'inverse,
cette couche est capable d'utiliser une seule connexion réseau pour transporter
plusieurs messages à la fois grâce au multiplexage. Dans tous les cas, tout
ceci doit être transparent pour la couche session.
Cette couche est également responsable du type de service à fournir à la couche
session, et finalement aux utilisateurs du réseau : service en mode
connecté ou non, avec ou sans garantie d'ordre de délivrance, diffusion du
message à plusieurs destinataires à la fois... Cette couche est donc également
responsable de l'établissement et du relâchement des connexions sur le réseau.
Un des tous derniers rôles à évoquer est le contrôle de flux.
C'est l'une des couches les plus importantes, car c'est elle qui fournit le
service de base à l'utilisateur, et c'est par ailleurs elle qui gère l'ensemble
du processus de connexion, avec toutes les contraintes qui y sont liées.
L'unité d'information de la couche réseau est le message.
Cette couche organise et
synchronise les échanges entre tâches distantes. Elle réalise le lien entre les
adresses logiques et les adresses physiques des tâches réparties. Elle établit
également une liaison entre deux programmes d'application devant coopérer et
commande leur dialogue (qui doit parler, qui parle...). Dans ce dernier cas, ce
service d'organisation s'appelle la gestion du jeton. La couche session permet
aussi d'insérer des points de reprise dans le flot de données de manière à
pouvoir reprendre le dialogue après une panne.
Cette couche s'intéresse à la
syntaxe et à la sémantique des données transmises : c'est elle qui traite
l'information de manière à la rendre compatible entre tâches communicantes.
Elle va assurer l'indépendance entre l'utilisateur et le transport de
l'information.
Typiquement, cette couche peut convertir les données, les reformater, les
crypter et les compresser.
Cette couche est le point de
contact entre l'utilisateur et le réseau. C'est donc elle qui va apporter à
l'utilisateur les services de base offerts par le réseau, comme par exemple le
transfert de fichier, la messagerie...
3.
Transmission
de données au travers du modèle OSI
Le processus émetteur remet les données à envoyer au
processus récepteur à la couche application qui leur ajoute un en-tête
application AH (éventuellement nul). Le résultat est alors transmis à la couche
présentation.
La couche présentation transforme alors ce message et lui ajoute (ou non) un
nouvel en-tête (éventuellement nul). La couche présentation ne connaît et ne
doit pas connaître l'existence éventuelle de AH ; pour la couche
présentation, AH fait en fait partie des données utilisateur. Une fois le
traitement terminé, la couche présentation envoie le nouveau
"message" à la couche session et le même processus recommence.
Les données atteignent alors la couche physique qui va effectivement
transmettre les données au destinataire. A la réception, le message va remonter
les couches et les en-têtes sont progressivement retirés jusqu'à atteindre le
processus récepteur :
Le concept important est le suivant : il faut considérer que chaque couche
est programmée comme si elle était vraiment horizontale, c'est à dire qu'elle
dialoguait directement avec sa couche paire réceptrice. Au moment de dialoguer
avec sa couche paire, chaque couche rajoute un en-tête et l'envoie
(virtuellement, grâce à la couche sous-jacente) à sa couche paire.
La chose la plus frappante à propos du modèle OSI est
que c'est peut-être la structure réseau la plus étudiée et la plus unanimement
reconnue et pourtant ce n'est pas le modèle qui a su s'imposer. Les
spécialistes qui ont analysé cet échec en ont déterminé 4 raisons principales.
4.1 - Ce n'était pas le bon moment
David Clark du MIT a émis la théorie
suivant quant à l'art et la manière de publier une norme au bon moment. Pour
lui, dans le cycle de vie d'une norme, il y a 2 pics principaux
d'activité : la recherche effectuée dans le domaine couvert par la norme,
et les investissements des industriels pour l'implémentation et la mise en
place de la norme. Ces deux pics sont séparés par un creux d'activité qui
apparaît être en fait le moment idéal pour la publication de la norme : il
n'est ni trop tôt par rapport à la recherche et on peut donc assurer une
certaine maîtrise, et il n'est ni trop tard pour les investissements et les
industriels sont prêts à utiliser des capitaux pour l'implémenter.
Le modèle OSI était idéalement placé par rapport à la recherche, mais hélas, le modèle TCP/IP était déjà en phase
d'investissement prononcé (lorsque le modèle OSI est sorti, les universités
américaines utilisaient déjà largement TCP/IP avec un certain succès) et les
industriels n'ont pas ressenti le besoin d'investir dessus.
4.2 - Ce n'était pas la bonne technologie
Le modèle OSI est peut-être
trop complet et trop complexe. La distance entre l'utilisation concrète
(l'implémentation) et le modèle est parfois importante.
En effet, peu de programmes peuvent utiliser ou utilisent mal l'ensemble des 7
couches du modèle : les couches session et présentation sont fort peu
utilisées et à l'inverse les couches liaison de données et réseau sont très
souvent découpées en sous-couches tant elles sont complexes.
OSI est en fait trop complexe pour pouvoir être proprement et efficacement
implémenté. Le comité rédacteur de la norme a même du laisser de côté certains
points techniques, comme le la sécurité et le codage, tant il était délicat de
conserver un rôle bien déterminé à chaque couche ainsi complétée. Ce modèle est
également redondant (le contrôle de flux et le contrôle d'erreur apparaissent
pratiquement dans chaque couche). Au niveau de l'implémentation, TCP/IP est
beaucoup plus optimisé et efficace.
La plus grosse critique que l'on peut faire au modèle est qu'il n'est pas du
tout adapté aux applications de télécommunication sur ordinateur !
Certains choix effectués sont en désaccord avec la façon dont les ordinateurs
et les logiciels communiquent. La norme a en fait fait
le choix d'un "système d'interruptions" pour signaler les événements,
et sur des langages de programmation de haut niveau, cela est peu réalisable.
4.3 - Ce n'était pas la bonne implémentation
Cela tient tout simplement du
fait que le modèle est relativement complexe, et que du coup les premières
implémentations furent relativement lourdes et lentes. A l'inverse, la première
implémentation de TCP/IP dans l'Unix de l'université de Berkeley (BSD) était
gratuite et relativement efficace. Historiquement, les gens ont donc eu une
tendance naturelle à utiliser TCP/IP.
4.4 - Ce n'était pas la bonne politique
Le modèle OSI a en fait
souffert de sa trop forte normalisation. Les efforts d'implémentation du modèle
étaient surtout "bureaucratiques" et les gens ont peut-être vu ça d'un mauvaise oeil.
A l'inverse, TCP/IP est venu d'Unix et a été tout de suite utilisé, qui plus
est par des centres de recherches et les universités, c'est-à-dire les premiers
a avoir utilisé les réseaux de manière poussée. Le
manque de normalisation de TCP/IP a été contre-balancé
par une implémentation rapide et efficace, et une utilisation dans un milieu
propice à sa propagation.
Au niveau de son utilisation et implémentation, et ce
malgré une mise à jour du modèle en 1994, OSI a clairement perdu la guerre face
à TCP/IP. Seuls quelques grands constructeurs dominant conservent le modèle
mais il est amené à disparaître d'autant plus vite qu'Internet (et donc TCP/IP)
explose.
Le modèle OSI restera cependant encore longtemps dans les mémoires pour
plusieurs raisons. C'est d'abord l'un des premiers grands efforts en matière de
normalisation du monde des réseaux. Les constructeurs ont maintenant tendance à
faire avec TCP/IP, mais aussi le WAP, l'UMTS etc. ce
qu'il devait faire avec OSI, à savoir proposer des normalisations dès le
départ. OSI marquera aussi les mémoires pour une autre raison : même si
c'est TCP/IP qui est concrètement utilisé, les gens ont tendance et utilisent
OSI comme le modèle réseau de référence actuel. En fait, TCP/IP et OSI ont des
structures très proches, et c'est surtout l'effort de normalisation d'OSI qui a
imposé cette "confusion" générale entre les 2 modèles. On a
communément tendance à considérer TCP/IP comme l'implémentation réelle de OSI.