Le modle OSI

1 - Introduction
2 - Les diffrentes couches du modle
2.1 - Les 7 couches
2.2 - La couche physique
2.3 - La couche liaison de donnes
2.4 - La couche rseau
2.5 - Couche transport
2.6 - La couche session
2.7 - La couche prsentation
2.8 - La couche application
3 - Transmission de donnes au travers du modle OSI
4 - Critique du modle 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 implmentation
4.4 - Ce n'tait pas la bonne politique
5 - L'avenir d'OSI
6 - Discussion autour de la documentation
7 - Suivi du document

1 - Introduction
Les constructeurs informatiques ont propos des architectures rseaux propres leurs quipements.
Par exemple, IBM a propos SNA, DEC a propos DNA... Ces architectures ont toutes le mme
dfaut : du fait de leur caractre propritaire, 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 htrognes, l'ISO (International Standards Organisation), organisme dpendant de
l'ONU et compos de 140 organismes nationaux de normalisation, a dvelopp un modle de
rfrence appel modle OSI (Open Systems Interconnection). Ce modle dcrit les concepts
utiliss et la dmarche suivie pour normaliser l'interconnexion de systmes ouverts (un rseau est
compos de systmes ouverts lorsque la modification, l'adjonction ou la suppression d'un de ces
systmes ne modifie pas le comportement global du rseau).

Au moment de la conception de ce modle, la prise en compte de l'htrognit des quipements

tait fondamentale. En effet, ce modle devait permettre l'interconnexion avec des systmes
htrognes 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 antrieurs. Cette prise en compte de
l'htrognit ncessite donc l'adoption de rgles communes de communication et de coopration
entre les quipements, c'est dire que ce modle devait logiquement mener une normalisation
internationale des protocoles.

Le modle OSI n'est pas une vritable architecture de rseau, car il ne prcise pas rellement les
services et les protocoles utiliser pour chaque couche. Il dcrit plutt ce que doivent faire les
couches. Nanmoins, l'ISO a crit ses propres normes pour chaque couche, et ceci de manire
indpendante au modle, i.e. comme le fait tout constructeur.
Les premiers travaux portant sur le modle OSI datent de 1977. Ils ont t bass sur l'exprience
acquise en matire de grands rseaux et de rseaux privs plus petits ; le modle devait en effet tre
valable pour tous les types de rseaux. En 1978, l'ISO propose ce modle sous la norme ISO
IS7498. En 1984, 12 constructeurs europens, rejoints en 1985 par les grands constructeurs
amricains, adoptent le standard.

2 - Les diffrentes couches du modle

2.1 - Les 7 couches
Le modle OSI comporte 7 couches :

Les principes qui ont conduit ces 7 couches sont les suivants :

- une couche doit tre cre lorsqu'un nouveau niveau d'abstraction est ncessaire,
- chaque couche a des fonctions bien dfinies,
- les fonctions de chaque couche doivent tre choisies dans l'objectif de la normalisation
internationale des protocoles,
- les frontires entre couches doivent tre choisies de manire minimiser le flux d'information aux
interfaces,
- le nombre de couches doit tre tel qu'il n'y ait pas cohabitation de fonctions trs diffrentes au sein
d'une mme couche et que l'architecture ne soit pas trop difficile matriser.
Les couches basses (1, 2, 3 et 4) sont ncessaires l'acheminement des informations entre les
extrmits concernes et dpendent du support physique. Les couches hautes (5, 6 et 7) sont
responsables du traitement de l'information relative la gestion des changes entre systmes
informatiques. Par ailleurs, les couches 1 3 interviennent entre machines voisines, et non entre les
machines d'extrmit qui peuvent tre spares par plusieurs routeurs. Les couches 4 7 sont au
contraire des couches qui n'interviennent qu'entre htes distants.

2.2 - La couche physique

La couche physique s'occupe de la transmission des bits de faon brute sur un canal de
communication. Cette couche doit garantir la parfaite transmission des donnes (un bit 1 envoy
doit bien tre reu comme bit valant 1). Concrtement, cette couche doit normaliser les
caractristiques lectriques (un bit 1 doit tre reprsent par une tension de 5 V, par exemple), les
caractristiques mcaniques (forme des connecteurs, de la topologie...), les caractristiques
fonctionnelles des circuits de donnes et les procdures d'tablissement, de maintien et de libration
du circuit de donnes.

L'unit d'information typique de cette couche est le bit, reprsent par une certaine diffrence de
potentiel.

2.3 - La couche liaison de donnes

Son rle est un rle de "liant" : elle va transformer la couche physique en une liaison a priori
exempte d'erreurs de transmission pour la couche rseau. Elle fractionne les donnes d'entre de
l'metteur en trames, transmet ces trames en squence et gre les trames d'acquittement renvoyes
par le rcepteur. Rappelons que pour la couche physique, les donnes n'ont aucune signification
particulire. La couche liaison de donnes doit donc tre capable de reconnatre les frontires des
trames. Cela peut poser quelques problmes, puisque les squences de bits utilises pour cette
reconnaissance peuvent apparatre dans les donnes.

La couche liaison de donnes doit tre capable de renvoyer une trame lorsqu'il y a eu un problme
sur la ligne de transmission. De manire gnrale, un rle important de cette couche est la dtection
et la correction d'erreurs intervenues sur la couche physique. Cette couche intgre galement une
fonction de contrle de flux pour viter l'engorgement du rcepteur.

L'unit d'information de la couche liaison de donnes est la trame qui est composes de quelques
centaines quelques milliers d'octets maximum.

2.4 - La couche rseau

C'est la couche qui permet de grer le sous-rseau, i.e. le routage des paquets sur ce sous-rseau et
l'interconnexion des diffrents sous-rseaux entre eux. Au moment de sa conception, il faut bien
dterminer le mcanisme de routage et de calcul des tables de routage (tables statiques ou
dynamiques...).

La couche rseau contrle galement l'engorgement du sous-rseau. On peut galement y intgrer

des fonctions de comptabilit pour la facturation au volume, mais cela peut tre dlicat.

L'unit d'information de la couche rseau est le paquet.

2.5 - Couche transport
Cette couche est responsable du bon acheminement des messages complets au destinataire. Le rle
principal de la couche transport est de prendre les messages de la couche session, de les dcouper
s'il le faut en units plus petites et de les passer la couche rseau, tout en s'assurant que les
morceaux arrivent correctement de l'autre ct. Cette couche effectue donc aussi le rassemblage du
message la rception des morceaux.

Cette couche est galement responsable de l'optimisation des ressources du rseau : en toute rigueur,
la couche transport cre une connexion rseau par connexion de transport requise par la couche
session, mais cette couche est capable de crer plusieurs connexions rseau par processus de la
couche session pour rpartir les donnes, par exemple pour amliorer le dbit. A l'inverse, cette
couche est capable d'utiliser une seule connexion rseau pour transporter plusieurs messages la
fois grce 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 rseau : service en mode connect ou non, avec ou sans garantie
d'ordre de dlivrance, diffusion du message plusieurs destinataires la fois... Cette couche est
donc galement responsable de l'tablissement et du relchement des connexions sur le rseau.

Un des tous derniers rles voquer est le contrle 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 gre l'ensemble du processus de connexion, avec toutes les
contraintes qui y sont lies.

L'unit d'information de la couche rseau est le message.

2.6 - La couche session

Cette couche organise et synchronise les changes entre tches distantes. Elle ralise le lien entre les
adresses logiques et les adresses physiques des tches rparties. Elle tablit galement une liaison
entre deux programmes d'application devant cooprer 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'insrer des points de reprise dans le flot de donnes de manire pouvoir
reprendre le dialogue aprs une panne.

2.7 - La couche prsentation

Cette couche s'intresse la syntaxe et la smantique des donnes transmises : c'est elle qui traite
l'information de manire la rendre compatible entre tches communicantes. Elle va assurer
l'indpendance entre l'utilisateur et le transport de l'information.

Typiquement, cette couche peut convertir les donnes, les reformater, les crypter et les compresser.

2.8 - La couche application

Cette couche est le point de contact entre l'utilisateur et le rseau. C'est donc elle qui va apporter
l'utilisateur les services de base offerts par le rseau, comme par exemple le transfert de fichier, la
messagerie...
3 - Transmission de donnes au travers du modle OSI
Le processus metteur remet les donnes envoyer au processus rcepteur la couche application
qui leur ajoute un en-tte application AH (ventuellement nul). Le rsultat est alors transmis la
couche prsentation.

La couche prsentation transforme alors ce message et lui ajoute (ou non) un nouvel en-tte
(ventuellement nul). La couche prsentation ne connat et ne doit pas connatre l'existence
ventuelle de AH ; pour la couche prsentation, AH fait en fait partie des donnes utilisateur. Une
fois le traitement termin, la couche prsentation envoie le nouveau "message" la couche session
et le mme processus recommence.

Les donnes atteignent alors la couche physique qui va effectivement transmettre les donnes au
destinataire. A la rception, le message va remonter les couches et les en-ttes sont progressivement
retirs jusqu' atteindre le processus rcepteur

Le concept important est le suivant : il faut considrer que chaque couche est programme comme
si elle tait vraiment horizontale, c'est dire qu'elle dialoguait directement avec sa couche paire
rceptrice. Au moment de dialoguer avec sa couche paire, chaque couche rajoute un en-tte et
l'envoie (virtuellement, grce la couche sous-jacente) sa couche paire.

4 - Critique du modle OSI

La chose la plus frappante propos du modle OSI est que c'est peut-tre la structure rseau la plus
tudie et la plus unanimement reconnue et pourtant ce n'est pas le modle qui a su s'imposer. Les
spcialistes qui ont analys cet chec en ont dtermin 4 raisons principales.
4.1 - Ce n'tait pas le bon moment
David Clark du MIT a mis la thorie suivant quant l'art et la manire 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 effectue dans le domaine couvert par la norme, et les investissements des industriels
pour l'implmentation et la mise en place de la norme. Ces deux pics sont spars par un creux
d'activit qui apparat tre en fait le moment idal pour la publication de la norme : il n'est ni trop
tt par rapport la recherche et on peut donc assurer une certaine matrise, et il n'est ni trop tard
pour les investissements et les industriels sont prts utiliser des capitaux pour l'implmenter.

Le modle OSI tait idalement plac par rapport la recherche, mais hlas, le modle TCP/IP tait
dj en phase d'investissement prononc (lorsque le modle OSI est sorti, les universits
amricaines utilisaient dj largement TCP/IP avec un certain succs) et les industriels n'ont pas
ressenti le besoin d'investir dessus.

4.2 - Ce n'tait pas la bonne technologie

Le modle OSI est peut-tre trop complet et trop complexe. La distance entre l'utilisation concrte
(l'implmentation) et le modle est parfois importante. En effet, peu de programmes peuvent utiliser
ou utilisent mal l'ensemble des 7 couches du modle : les couches session et prsentation sont fort
peu utilises et l'inverse les couches liaison de donnes et rseau sont trs souvent dcoupes en
sous-couches tant elles sont complexes.

OSI est en fait trop complexe pour pouvoir tre proprement et efficacement implment. Le comit
rdacteur de la norme a mme du laisser de ct certains points techniques, comme le la scurit et
le codage, tant il tait dlicat de conserver un rle bien dtermin chaque couche ainsi complte.
Ce modle est galement redondant (le contrle de flux et le contrle d'erreur apparaissent
pratiquement dans chaque couche). Au niveau de l'implmentation, TCP/IP est beaucoup plus
optimis et efficace.

La plus grosse critique que l'on peut faire au modle est qu'il n'est pas du tout adapt aux
applications de tlcommunication sur ordinateur ! Certains choix effectus sont en dsaccord avec
la faon dont les ordinateurs et les logiciels communiquent. La norme a en fait fait le choix d'un
"systme d'interruptions" pour signaler les vnements, et sur des langages de programmation de
haut niveau, cela est peu ralisable.

4.3 - Ce n'tait pas la bonne implmentation

Cela tient tout simplement du fait que le modle est relativement complexe, et que du coup les
premires implmentations furent relativement lourdes et lentes. A l'inverse, la premire
implmentation 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 modle OSI a en fait souffert de sa trop forte normalisation. Les efforts d'implmentation du
modle 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 universits, c'est--dire les premiers a avoir utilis les rseaux de manire pousse.
Le manque de normalisation de TCP/IP a t contre-balanc par une implmentation rapide et
efficace, et une utilisation dans un milieu propice sa propagation.
5 - L'avenir d'OSI
Au niveau de son utilisation et implmentation, et ce malgr une mise jour du modle en 1994,
OSI a clairement perdu la guerre face TCP/IP. Seuls quelques grands constructeurs dominant
conservent le modle mais il est amen disparatre d'autant plus vite qu'Internet (et donc TCP/IP)
explose.

Le modle OSI restera cependant encore longtemps dans les mmoires pour plusieurs raisons. C'est
d'abord l'un des premiers grands efforts en matire de normalisation du monde des rseaux. 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 ds le dpart. OSI marquera aussi les
mmoires pour une autre raison : mme si c'est TCP/IP qui est concrtement utilis, les gens ont
tendance et utilisent OSI comme le modle rseau de rfrence actuel. En fait, TCP/IP et OSI ont
des structures trs proches, et c'est surtout l'effort de normalisation d'OSI qui a impos cette
"confusion" gnrale entre les 2 modles. On a communment tendance considrer TCP/IP
comme l'implmentation relle de OSI.