BTS IG Informatique de Gestion

AMSI:Modele OSI

Le modèle d'interconnexion en Réseau informatique des systèmes ouverts de l'ISO (Organisation internationale de normalisation) est un modèle (informatique) de communications entre ordinateurs. Il décrit les fonctionnalités nécessaires à la communication et l'organisation de ces fonctions.

La norme complète porte la référence ISO 7498 et est intitulée « Modèle basique de référence pour l'interconnexion des systèmes ouverts (OSI) Â»

Présentation de la norme

L'objectif de cette norme est de spécifier un cadre général pour la création de normes ultérieures cohérentes. Le modèle lui-même ne définit pas de service particulier et encore moins de protocole.

Concepts et terminologie: services, protocoles et interfaces

Le modèle est essentiellement une architecture en couches définies et délimitées avec les notions de service, de Protocole de communication et d'interface.

• Un service est une description abstraite de fonctionnalités à l'aide de primitives (commandes ou évènements) telles que demande de connexion ou réception de données.
• Un protocole est un ensemble de messages et de règles d'échanges réalisant un service.
• Une interface ("point d'accès au service" dans la norme) est le moyen concret d'utiliser le service. Dans un programme, c'est typiquement un ensemble de fonctions de bibliothèque ou d'appels systèmes. Dans une réalisation matérielle, c'est par exemple un jeu de registres a l'entrée d'un circuit.

Les détails d'un service varient bien sûr d'une architecture de réseau à l'autre. La classification la plus grossière se fait selon que le service fonctionne en mode connecté ou non. Malgré cette variabilité, les fonctions communes ont des noms conventionnellement constants. Ces noms ne proviennent toutefois pas directement de ISO 7498-1.

• connection.request : est une demande de connexion sortante, i.e. à l'initiative d'une entité locale.
• connection.indication : correspond à l'évènement «Une demande de connexion entrante a été reçue.».
• connection.response : est l'indication d'acceptation ou de rejet de la connexion
• connection.confirmation : correspond à l'évènement «La réponse du demandé a été reçue.». C'est un acquittement.
• data.request, data.indication et data.confirm : sont le pendant pour les données.

Les données fournies à une primitive de service sont appelées (N)-SDU ("Service Data Unit") où N est l'indication de la couche, son numéro dans la norme, parfois une lettre tirée du nom de la couche. Les messages d'un protocole sont appelés PDU ("Protocol Data Unit").

Architecture en couche

Le modèle comporte 7 couches succinctement présentées ci-dessous de bas en haut et détaillées dans leur articles respectifs. Ces couches sont parfois réparties en 2 groupes.

Les 4 couches inférieures sont plutôt orientées communication et sont typiquement fournies par un système d'exploitation.

Les 3 couches supérieures sont plutôt orientées application (informatique) et plutôt réalisées par des bibliothèques ou un programme spécifique. Dans le monde IP, ces 3 couches sont rarement distinguées. Dans ce cas, toutes les fonctions de ces couches sont considérées comme partie intégrante du protocole applicatif.

Par ailleurs, les couches basses sont normalement transparentes pour les données à transporter, alors que les couches supérieures ne le sont pas nécessairement, notamment au niveau présentation.

Dans une telle architecture, une « entité Â» de niveau (N+1) envoie des données avec la primitive "data.request" de l'entité de niveau (N) en lui fournissant comme données un (N+1)-PDU qui sera typiquement, à son tour encapsulé dans un (N)-PDU. Coté récepteur, chaque entité analyse l'enveloppe protocole correspondant à sa couche et transmet les données à la couche supérieure sous la forme d'une primitive "data.indication".

Certaines fonctions comme la détection des erreurs de transmission et leur correction, le contrôle de flux peuvent être présentes dans plusieurs couches. Ces fonctions sont décrites globalement plus loin.

Caractérisation résumée des couches

La caractérisation donnée ici est tirée du chapitre 7 de ISO 7498-1. La description originelle donne en plus pour chaque couche les fonctions de manipulation de commandes ou de données significatives parmi celles décrites plus bas.

• 7) La Couche physique est chargée de la transmission effective des signaux entre les interlocuteurs. Son service est typiquement limité à l'émission et la réception d'un bit ou d'un train de bit continu (notamment pour les supports synchrones).
• 6) La Couche de liaison gère les communications entre 2 machines adjacentes, directement reliées entre elles par un support physique.
• 5) La Couche de réseau gère les communications de bout en bout, généralement entre machines : routage et adressage des paquets.(cf. note ci-dessous).
• 4) La Couche de transport gère les communications de bout en bout entre processus (programmes en cours d'exécution).
• 3) La Couche de session gère la synchronisation des échanges et les «transactions», permet l'ouverture et la fermeture de session.
• 2) La Couche de présentation est chargée du codage des données applicatives, précisément de la conversion entre données manipulées au niveau applicatif et chaînes d'octets effectivement transmises.
• 1) La Couche application est le point d'accès aux services réseaux, elle n'a pas de service propre spécifique et entrant dans la portée de la norme.

Un moyen mnémotechnique pour se souvenir des 7 couches :

Après Plusieurs Semaines Tout Respire La Paix

Quelques précisions

Lorsque les services réseau et transport fonctionnent tous les deux en mode connecté, il n'y a pas toujours de distinction claire entre ces deux services. Il y a toutefois deux cas ou cela est très simple :

• Si le service réseau n'autorise qu'une seule connexion entre 2 machines : dans ce cas, les connexions de niveau transport sont nécessairement multiplexées sur une connexion de niveau réseau et la distinction est nette.
• Les services des 2 couches relatifs à la correction des erreurs sont différents : Ces fonctions peuvent n'être présentes que dans une seule des 2 couches.

Fud9Sg <a href="http://mbnoqhqaimom.com/">mbnoqhqaimom</a>, [url=http://bygpundgixnl.com/]bygpundgixnl[/url], [link=http://rqwsxzafmbwm.com/]rqwsxzafmbwm[/link], http://wvpuomzgmmyv.com/

Limitations du modèle et utilisations étendues

Cette section illustre quelques cas ou une architecture réseau ne peut entrer complètement dans la cadre du modèle OSI.

Le modèle prévoit que dans une pile concrète, il y ait un et un seul protocole par couche. Il y a toutefois des cas ou cela est quasi-impossible, en particulier lors de l'interconnexion de réseaux hétérogènes, c’est-à-dire utilisant des jeux de protocole différents. Par exemple, un tunnel simple permet de relier 2 réseaux homogènes en traitant un réseau d'un autre type comme une connexion point à point. C'est cette technique qui est utilisée pour relier temporairement une machine isolée à Internet (hors lignes xDSL): Un modem gère une connexion téléphonique entre 2 machines distantes, donc une connexion de niveau 3 dans la pile RNIS, et l'utilise pour transmettre des trames PPP, protocole de niveau 2 alors que dans une pile canonique, cela serait des PDU de niveau transport (4).

Il y a aussi desison du service fourni et du service attendu de la couche inférieure l'exige. Ainsi, dans le monde IP, les protocoles SSL et TCP fournissent tous deux un service de communication point à point entre processus mais le seul protocole standard réalisant le service attendu par SSL pour fonctionner n'est fourni que par TCP. On est donc obligé de superposer SSL sur TCP.

Dans certaines architectures réseau, le service offert aux machines d'extrémité n'est pas suffisant pour satisfaire les besoins internes au réseau. Par exemple, dans un réseau ATM, le service réseau est en mode connecté. Il faut donc une pile protocolaire capable de transporter la signalisation (les messages de gestion des connexions) mais le service offert par cette pile n'est pas accessible aux machines d'extrémité. Pour modéliser cela, on superpose au découpage «horizontal» en couche, un découpage «vertical» en «plan» dans lequel les piles protocolaires sont indépendantes. Ainsi, un modèle de réseau ATM est constitué de 3 plans: le plan usager pour les données ordinaires, le plan de contrôle pour le transport de la signalisation et un plan de gestion pour la supervision interne au réseau. Les réseaux téléphoniques (réseaux fixes RNIS et réseaux UMTS) ont aussi un découpage en plan similaire.

Le monde IP et le modèle OSI

S'il y a bien une correspondance grossière entre les protocoles de la pile IP et les couches du modèle, on ne peut pas considérer que la pile IP est vraiment compatible avec le modèle. En particulier, la séparation des couches dans la pile IP est nettement plus approximative. En voici 2 illustrations.

Pour être conforme au modèle, un protocole d'une pile ne doit pas dépendre des protocoles des autres couches, mais uniquement du service fourni. A titre d'exemple de non-conformité, considérons la détection des erreurs dans une pile IP. Les 2 protocoles TCP et UDP ont dans leur en-tête une somme de contrôle pour la détection des erreurs. Le calcul de cette somme fait intervenir une partie de l'en-tête IP. Les protocoles TCP et UDP ne sont donc pas indépendants de IP. Cela se remarque notamment au fait que lors de passage de IP version 4 à IP version 6, il faut redéfinir la façon de calculer ces somme de contrôle alors que les protocoles eux-même n'ont pas réellement changé.

Lorsqu'un "datagramme" UDP, protocole de niveau transport en principe, arrive à une adresse (paire <adresse IP, numéro de port>) alors qu'il n'a pas de processus destinataire, l'erreur est signalée à l'émetteur en lui envoyant un paquet ICMP indiquant «port inaccessible». Or ICMP est en principe un protocole de niveau réseau. La machine recevant ce paquet doit donc examiner la partie données de ce paquet pour déterminer le processus devant recevoir la notification d'erreur. Différence de protocole et perte de transparence des données sont 2 cas de mauvaise séparation des couches. Notons à cette occasion que TCP a en revanche un mécanisme normal pour cette situation: la levée de l'indicateur RST dans le message d'erreur.

Quelques protocoles

• Couche application : Gopher - SSH - NNTP - DNS - SNMP - XMPP - SMTP - POP3 - IMAP - IRC - VoIP - WebDAV - SIMPLE - HTTP
• Couche de présentation : Videotex - Unicode - MIME - HTML - XML - TDI - ASN.1 - XDR - UUCP - NCP - AFP - SSP
• Couche de session : RTSP - H.323 - SIP - AppleTalk
• Couche de transport : TCP - UDP - ICMP - SCTP - RTP - SPX - TCAP - DCCP
• Couche de réseau : NetBEUI - IPv4 - IPv6 - ARP - IPX - BGP - ICMP - OSPF - RIP - IGMP - IS-IS - CLNP - WDS - ATM
• Couche de liaison : Ethernet - Anneau à jeton - LocalTalk - FDDI - X.21 - X.25 - Frame Relay - BitNet - CAN - Wi-Fi - PPP - HDLC
• Couche physique : CSMA/CD - CSMA/CA - Codage NRZ - Codage Manchester - Codage Miller - RS-232 - RS-449 - V.21-V.23 - V.42-V.90 - Câble coaxial - 10Base2 - 10BASE5 - Paire torsadée - 10BASE-T - 100BASE-TX - ISDN - PDH - SDH - T-carrier - EIA-422 - EIA-485 - SONET - ADSL - SDSL - VDSL - DSSS - FHSS - HomeRF - IrDA - USB - IEEE 1394 - Wireless USB, Bluetooth

Sources

Wikipedia