SlideShare una empresa de Scribd logo
1 de 33
Descargar para leer sin conexión
s Architecture générale s
____
B. Cousin et C. Viho - © IFSIC -Université Rennes I 94
Chapitre 4 : Architecture générale des réseaux informatiques
/udd/bcousin/Pages-web-Armor/Enseignement/Reseaux-generalites/Cours/4.recover.fm - 1 juin 2001 18:28
Plan
- 1. Introduction p95
- 2. Le modèle de référence OSI de l’ISO p98
- 3. Quelques fonctions p112
- 4. Autres exemples d’architecture de réseaux p118
- 5. Normalisation des réseaux p120
- 6. Conclusion p123
- 7. Quelques commentaires p124s
Bibliographie
- Reference model for open systems interconnection : ISO 7498, UIT-T.200
- G. Pujolle, Les réseaux, Eyrolles, 1995. Chapitre 3.
- H. Nussbaumer, Téléinformatique, Presses Polytechniques romandes, 1987. Chapitre 1.3.
- A.Tanenbaum, Réseaux, 3ème éd., InterEditions, 1997. Chapitre 1.
s Architecture générale s
____
B. Cousin et C. Viho - © IFSIC -Université Rennes I 95
1. Introduction
Les réseaux informatiques doivent permettre à des applications informatiques de coopérer sans
avoir à tenir compte de l’hétérogénéité des moyens et procédés de transmission (par exemple : de la
topologie, des méthodes d’accès, des caractéristiques des équipements ou des supports, etc.).
. Adapter la technologie de transmission au support de communication
. Masquer les phénomènes altérant la transmission
. Maintenir la qualité demandée
. Offrir l’interopérabilité (1)
. Optimiser l’utilisation des ressources (2)
. Assurer la pérennité des choix (3)
(1) + (2) + (3) ==> Normalisation
SNA
IBM
DEC
BULL
DSA
DECnet
SNA/DECnet
DSA/DECnet
SNA/DSA
OSI
IBM
DEC
BULL
OSI
OSI
s Architecture générale s
____
B. Cousin et C. Viho - © IFSIC -Université Rennes I 96
1.1. Objectif
Réduire la complexité de conception des réseaux informatiques.
Principes :
- démarche analytique : recensement des fonctions nécessaires
- démarche synthétique : classement des fonctions
- démarche simplificatrice et constructive :
. regroupement en sous-ensembles pour simplifier la compréhension des fonctions (fron-
tières précises, concises et utiles)
. décomposition hiérarchique de l’ensemble des mécanismes à mettre en œuvre en une
série de couches (ou niveaux).
Remarque :
Le nombre de couches, leurs noms et leurs fonctions varient selon les types de réseaux
Exemples :
le modèle de référence de l’OSI : 7 couches
LAN : 2 + 2 sous-couches; ATM : 2 + 1 + 3 sous-couches, Internet : 3 ou 4 couches
s Architecture générale s
____
B. Cousin et C. Viho - © IFSIC -Université Rennes I 97
1.2. Principes de base de la décomposition en couches
Une couche doit être créée lorsqu’un nouveau niveau d’abstraction est nécessaire
Chaque couche exerce une fonction bien définie
Les fonctions de chaque couche doivent être choisies en pensant à la définition des protocoles nor-
malisés internationaux
Le choix des frontières entre couches doit minimiser le flux d’informations aux interfaces
Le nombre de couches doit être :
- suffisamment grand pour éviter la cohabitation dans une même couche de fonctions très dif-
férentes, et
- suffisamment petit pour éviter que l’architecture ne devienne difficile à maîtriser.
s Architecture générale s
____
B. Cousin et C. Viho - © IFSIC -Université Rennes I 98
2. Le modèle de référence OSI de l’ISO
2.1. Présentation
Norme de description de l’architecture générale des réseaux informatiques:
- L’OSI = “Open Systems Interconnection : reference model”
- modèle en 7 couches
Les noms de la norme :
- ISO : IS 7498
- CCITT : X200 (nouvellement IUT-T)
- AFNOR : NF.Z.70.001
s Architecture générale s
____
B. Cousin et C. Viho - © IFSIC -Université Rennes I 99
2.2. Notion de couche, de protocole et de service
Une couche est spécialisée dans un ensemble de fonctions particulières. Elle utilise les fonction-
nalités de la couche inférieure et propose ses fonctionnalités à la couche supérieure.
Un système est un ensemble de composants formant un tout autonome.
Une entité est l’élément actif d’une couche dans un système.
- entités homologues (paires) : entités de même couche situées dans des systèmes distants
Le protocole d’une couche N définit l’ensemble des règles ainsi que les formats et la signification
des objets échangés, qui régissent la communication entre les entités de la couche N.
Le service d’une couche N définit l’ensemble des fonctionnalités possédées par la couche N et
fournies aux entités de la couche N+1 à l’interface N/N+1.
Notation : on note N_X (ou encore X(N)) l’objet de type X appartenant à la couche N.
- ex : N-entité ou entité(N)
s Architecture générale s
____
B. Cousin et C. Viho - © IFSIC -Université Rennes I 100
L’architecture d’un réseau est définie par l’ensemble des couches et la description des protocoles
et des services de chacune d’elles.
Couche (N)
Couche (N+1)
Couche (N-1)
entité A entité B InterfacesProtocole de couche N
d’accès au
service
Service de la couche N
Service de la couche N-1
Système A Système B
s Architecture générale s
____
B. Cousin et C. Viho - © IFSIC -Université Rennes I 101
2.3. Architecture générale du modèle OSI
Le modèle OSI possède sept couches
Le modèle décrit simplement ce que chaque couche doit réaliser (le service), les règles et le format
des échanges (le protocole), mais pas leur implantation.
Physique
Couches
Liaison de données
Réseau
Transport
Session
Présentation
Application
Nom des unités de
données échangées
A-PDU
P-PDU
S-PDU
T-PDU/Message
N-IPDU/Paquet
L-PDU/Trame
Bit
Support physique d’interconnexion
Protocole d’application
Protocole de présentation
Protocole de session
Protocole de transport
système intermédiaire
CoucheshautesCouchesbasses
système d’extrémité
s Architecture générale s
____
B. Cousin et C. Viho - © IFSIC -Université Rennes I 102
2.4. Les sept couches du modèle OSI
2.4.1 La couche Physique (couche 1)
Fournit les moyens mécaniques, optiques, électroniques, fonctionnels et procéduraux nécessaires
à l’activation, au maintien et à la désactivation des connexions physiques nécessaires à la transmission
de trains de bits.
Note : les systèmes sont interconnectés réellement au moyen de supports physiques de communi-
cation. Ces derniers ne font pas partie de la couche Physique.
2.4.2 La couche Liaison de données (couche 2)
Assure la transmission d’informations entre (2 ou plusieurs) systèmes immédiatement adjacents.
Détecte et corrige, dans la mesure du possible, les erreurs issues de la couche inférieure. Les objets
échangés sont souvent appelés trames (“frames”).
2.4.3 La couche Réseau (couche 3)
Achemine les informations à travers un réseau pouvant être constitué de systèmes intermédiaires
(routeurs). Les objets échangés sont souvent appelés paquets (“packets”).
s Architecture générale s
____
B. Cousin et C. Viho - © IFSIC -Université Rennes I 103
2.4.4 La couche Transport (couche 4)
Assure une transmission de bout en bout des données. Maintient une certaine qualité de la trans-
mission, notamment vis-à-vis de la fiabilité et de l’optimisation de l’utilisation des ressources. Les ob-
jets échangés sont souvent appelés messages (de même pour les couches supérieures).
2.4.5 La couche Session (couche 5)
Fournit aux entités coopérantes les moyens nécessaires pour synchroniser leurs dialogues, les in-
terrompre ou les reprendre tout en assurant la cohérence des données échangées.
2.4.6 La couche Présentation (couche 6)
Se charge de la représentation des informations que les entités s’échangent. Masque l’hétérogénéi-
té de techniques de codage utilisées par les différents systèmes.
2.4.7 La couche Application (couche 7)
Donne aux processus d’application les moyens d’accéder à l’environnement de communication de
l’OSI. Comporte de nombreux protocoles adaptés aux différentes classes d’application.
Note : les fonctionnalités locales des applications proprement dites sont hors du champ de l’OSI
donc de la couche Application !
s Architecture générale s
____
B. Cousin et C. Viho - © IFSIC -Université Rennes I 104
2.4.8 Conclusion
Les trois premières couches constituent les couches basses où les contraintes du réseau sont per-
ceptibles. Fonctions élémentaires spécialisées dans la transmission.
La couche Transport est une couche charnière, d’adaptation ou intermédiaire, associée le plus sou-
vent aux couches basses.
Les trois dernières couches constituent les couches hautes où les contraintes de l’application sont
perceptibles. Fonctions complexes et variables adaptées aux traitements applicatifs.
Attention : La norme stipule clairement qu’il s’agit d’un modèle de référence et par conséquent,
suivant le contexte dans lequel on se trouve et les besoins de communication, certaines fonctionnalités
de certaines couches peuvent ne pas être utilisées (protocoles alternatifs, classes de protocole, options,
etc.).
s Architecture générale s
____
B. Cousin et C. Viho - © IFSIC -Université Rennes I 105
2.5. Connexion
SAP(N) : “service access point”
- point identifié où les services sont fournis par l’entité(N) à une entité(N+1)
. ex : adresse
Connexion(N) : association d’entités homologues pour le transfert de données
- entités correspondantes : entités associées par la même connexion
Extrémité de connexion(N) : terminaison d’une connexion(N) à un SAP(N).
- connexion bipoint : connexion comportant exactement 2 extrémités.
- connexion multipoint : connexion comportant plus de 2 extrémités.
entité(N+1)
entité(N) entité(N)
SAP(N)
entité(N+1) entité(N+1)
SAP(N)
connexion(N)
entités correspondantescouche N+1
couche N
Interface N
s Architecture générale s
____
B. Cousin et C. Viho - © IFSIC -Université Rennes I 106
2.6. Les modes de communication
On peut distinguer deux grands modes de communication:
- communication en mode connecté (appelé aussi “with connection”)
- communication en mode non connecté (appelé aussi “connectionless” ou par abus de lan-
gage “datagramme”)
2.6.1 Le mode non connecté
- 1 seule phase (ou 0!) :
. le transfert de données
- chaque unité de transfert de données est acheminée indépendamment
- les entités communicantes ne mémorisent rien (“memoryless”).
- les messages échangées sont auto-suffisants (“self-content”)
s Architecture générale s
____
B. Cousin et C. Viho - © IFSIC -Université Rennes I 107
2.6.2 Le mode connecté
- 3 phases :
. phase d’établissement de la connexion
. phase de transfert de données
. phase de libération de la connexion
- un contexte (réparti) est partagé par les membres de la connexion :
. par exemple : le numéro du paquet
- permet (facilite) le contrôle et la gestion du transfert de données :
. contrôle d’erreur, contrôle de flux, maintien en séquence, etc.
- les messages échangés comportent des informations qui ne sont utilisables que grâce à la
connaissance de ce contexte :
. par exemple : le numéro de paquet / la largeur de la fenêtre coulissante
s Architecture générale s
____
B. Cousin et C. Viho - © IFSIC -Université Rennes I 108
2.7. Les primitives de service
Le protocole(N) s’appuie sur le service(N-1), donc la description du service est nécessaire à la
compréhension du protocole.
Attention, le service n’est accessible qu’à l’intérieur d’un système : la façon d’accéder au service
ne doit pas être normalisée !
Les primitives spécifient le service :
- Ce sont des objets abstraits (puisque le service est abstrait !)
- Echangées à travers un interface idéal (sans perte et sans délai)
- Leur représentation ressemble à une procédure avec des paramètres
. préfixe : l’initiale de la couche
. suffixe : le type de primitive
. Exemples :
. T_Data.req(T_SDU)
. LLC_Data.req(ad-locale, ad-distante, L_SDU, classe-de-service)
s Architecture générale s
____
B. Cousin et C. Viho - © IFSIC -Université Rennes I 109
Il existe quatre types de primitives :
- Request : Une entité sollicite un service
- Indication : Une entité est informée d’une demande de service
- Response : Une entité a rendu le service, si possible
- Confirmation : Une entité est informée que le service a été rendu
Par exemple :
De très nombreuses variantes d’enchaînement des types de primitives de service [1 à 4] existent !
Service confirmé
(Couche N)(Couche N+1) (Couche N+1)
N-xxx.req(...)
N-xxx.ind(...)
Fournisseur
du service
N-xxx.resp(...)
N-xxx.conf(...)
Utilisateur
du service A
Utilisateur
du service B
Service non confirmé
(Couche N)(Couche N+1) (Couche N+1)
N-xxx.req(...)
N-xxx.ind(...)
Fournisseur
du service
Utilisateur
du service A
Utilisateur
du service B
Temps
Temps
s Architecture générale s
____
B. Cousin et C. Viho - © IFSIC -Université Rennes I 110
2.8. Les unités de données
SDU(N) :
- unité de données spécifique au service(N), dont l’intégrité est préservée d’une extrémité à
l’autre d’une connexion. Mais pas forcément entre !
. potentiellement de taille quelconque.
. exemple : un fichier à transmettre
PDU(N) :
- unité de données spécifique au protocole(N), adaptée à la transmission, constituée par les
informations de contrôle du protocole (PCI(N)) et éventuellement par des portions de don-
nées issues du SDU(N)
. par ex. : une trame, un paquet.
s Architecture générale s
____
B. Cousin et C. Viho - © IFSIC -Université Rennes I 111
IDU(N) :
- unité d’information transférée en une seule interaction à l’interface de 2 couches, constituée
d’information de contrôle d’interface (ICI(N)) et tout ou partie d’une SDU(N).
. dépend du système d’accueil (notamment leur format).
. dépendant de l’implantation
. par ex. : les tampons (buffers) utilisés pour charger le fichier
(N)PCI
(N)SDU
Couche N+1
Interface
Couche N
Les entités de couche N
échangent des N-PDU
par le protocole de
la couche N
(N+1)PDU
(N)PDU
(pas de segmentation ni de blocage)
s Architecture générale s
____
B. Cousin et C. Viho - © IFSIC -Université Rennes I 112
3. Quelques fonctions
Ces fonctions peuvent être présentes dans n’importe quelle couche.
3.1. Multiplexage/démultiplexage
Fonction d’une couche(N) permettant de prendre en charge plusieurs connexions(N) sur une seule
connexion(N-1)
- Optimise l’utilisation de la connexion(N-1)
- Permet l’établissement simultané de plusieurs connexions(N) alors qu’une seule con-
nexion(N-1) existe
- Problème : identification des connexions, contrôle des différents flux
Exemple : multiplexage de plusieurs connexions de Transport sur une seule connexion de Réseau
couche(N) N-connexions
N-1-connexion
s Architecture générale s
____
B. Cousin et C. Viho - © IFSIC -Université Rennes I 113
3.2. Eclatement/recombinaison
Fonction d’une couche(N) permettant d’utiliser plusieurs connexions(N-1) pour prendre en charge
une connexion(N).
- Amélioration de la fiabilité grâce à la redondance
- Amélioration des performances malgré l’usage de connexions(N-1) peu performantes
- Problème : dé-séquencement
- Appelé aussi multiplexage aval.
Exemple : HDLC multiliaison (“multilink”)
couche(N) N-connexion
N-1-connexions
s Architecture générale s
____
B. Cousin et C. Viho - © IFSIC -Université Rennes I 114
3.3. Segmentation/réassemblage
Fonction d’une couche(N) mettant en correspondance une SDU(N) avec plusieurs PDU(N)
- Adaptation de la taille des données (N-SDU) aux caractéristiques de transmission (N-PDU)
- Problème : identification des PDU transportant les données constituant la SDU.
Exemple : les fragments d’un datagramme IP
(N)PCI
Couche N+1
Interface
Couche N
(N)PDU (N)PDU
(N)SDU
s Architecture générale s
____
B. Cousin et C. Viho - © IFSIC -Université Rennes I 115
3.4. Groupage/dégroupage
Fonction d’une couche(N) mettant en correspondance plusieurs SDU(N) avec une seule PDU(N)
- Adaptation de la taille des données (N-SDU) aux caractéristiques de la transmission (N-
PDU)
- Diminution du surcoût (overhead)
- Problème : identification des SDU transportées.
Exemple : la “bufferisation” des données sous TCP
(N)PCI
Couche N+1
Interface
Couche N
(N)PDU
(N)SDU (N)SDU
s Architecture générale s
____
B. Cousin et C. Viho - © IFSIC -Université Rennes I 116
3.5. Concaténation/séparation
Fonction d’une couche (N) mettant en correspondance plusieurs PDU(N) avec une seule SDU(N)
- Adaptation de la taille des données aux caractéristiques du service (N-SDU)
- Diminution du surcoût (overhead)
- Problème : identification des PDU transportées
Exemple : Concaténation des commandes et des données de la couche Transport.
Couche N-1
Couche N
(N-1)SDU
(N)PDU (N)PDU
s Architecture générale s
____
B. Cousin et C. Viho - © IFSIC -Université Rennes I 117
3.6. Transmission de données
L’encapsulation :
- Les données d’une couche sont encapsulées dans une unité de données de la couche infé-
rieure.
- Par ex. : la lettre dans l’enveloppe dans le sac postal dans le train postal.
données
Physique
Liaison
Réseau
Transport
Session
Présentation
Application
Physique
Liaison
Réseau
Transport
Session
Présentation
Application
message
paquet
trame
processus émission processus réception
donnéesAH
PH
SH
TH
NH
DH DE
signal codant le train de bits
support de transmission
systèmeA
systèmeB
s Architecture générale s
____
B. Cousin et C. Viho - © IFSIC -Université Rennes I 118
4. Autres exemples d’architecture de réseaux
4.1. Architecture des réseaux locaux
couche
Physique
couche
Liaison de
données sous-couche MAC
(Medium Access
Control)
sous-couche LLC
(Logical Link
Control)
(Ethernet, Token Ring, Token Bus, FDDI, etc.)
correspondance
avec l’OSI
sous-couche PMD
Architecture des réseaux locaux
couches supérieures
sous-couche PHY
s Architecture générale s
____
B. Cousin et C. Viho - © IFSIC -Université Rennes I 119
4.2. Architecture générale d’Internet
couche
Physique
couche
Liaison de
données
correspondance
avec l’OSI
Architecture du monde Internet
couches applicatives
couche
Réseau
couche
Transport
TCP
Control
Protocol)
(Transmission
UDP
(User Datagram
Protocol)
IP (Internet Protocol)
Toutes sortes de protocoles
offrant l’équivalent des
fonctionnalités des couches 1 et 2
du modèle OSI
Les protocoles applicatifs
d’Internet : telnet, ftp, http,
smtp, dns, nfs, snmp, xdr, etc.
s Architecture générale s
____
B. Cousin et C. Viho - © IFSIC -Université Rennes I 120
5. Normalisation des réseaux
La normalisation garantit l’interfonctionnement et une certaine pérennité, diffusion ou efficacité
ou de l’objet produit à partir de ces normes.
5.1. Les principaux organismes de normalisation, dans le domaine des réseaux numériques
- ISO (International Standardization Organization)
- IUT-T (International Union of Telecommunication - section Telecommunication) (ex-
CCITT)
- IEEE (Institute of Electrical and Electronic Engineers)
- IETF / IRTF (Internet Engineering/Research Task Force)
- ANSI, ECMA, AFNOR, etc.
Différents types
de protocoles
Développement
de nouvelles technologies
Besoin croissant
de communication
Nécessité de définir des normes
s Architecture générale s
____
B. Cousin et C. Viho - © IFSIC -Université Rennes I 121
5.2. Identification des normes et exemples de normes
La dénomination d’une norme doit tenir compte d’un ensemble de critères :
- son origine (ISO, IEEE, etc)
- son domaine d’application (réseaux publics/privés/locaux/, téléphone, etc)
- sa zone d’application (européenne, internationale, etc)
Exemples de normes :
Les normes ISO sont préfixées par IS (International Standard)
. ISO/ IS 8208 (=X.25/L3), ISO / IS 8802.3 (=Ethernet), etc.
Les normes IUT-T sont nommées à l’aide d’une lettre suivie d’un point et d’un numéro :
. IUT-T / X.25, IUT-T / X.400 (Messagerie), IUT-T / V.24 (Jonction pour la transmission
de données numériques sur lignes téléphoniques), etc.
Les noms des normes IEEE :
. IEEE 802.5 (Token Ring), etc.
Les normes de l’IETF/IRTF sont appelées des RFC (“Request For Comments”) :
. RFC 791 (Internet Protocol), RFC 768 (UDP), RFC 793 (TCP), …
s Architecture générale s
____
B. Cousin et C. Viho - © IFSIC -Université Rennes I 122
5.3. Cycle de vie d’une norme
Une norme est généralement développée au sein d’un groupe de travail ad hoc.
- production de “draft”
- expérimentation
- la norme est généralement la (meilleure) réponse technique à un problème en fonction des
connaissances de l’époque.
Une norme est adoptée par des instances officielles
- après un vote formel
- la norme est publique et publiée
- la norme répond a des compromis économiques … et politiques
Une norme est généralement révisée :
- périodiquement
- une norme peut être écartée et même disparaître
s Architecture générale s
____
B. Cousin et C. Viho - © IFSIC -Université Rennes I 123
6. Conclusion
Modèle de référence pour l’interconnexion des systèmes informatiques hétérogènes :
- en 7 couches (P, LdD, N, T, S, P, A)
Mais ce ne doit pas être un dogme immuable, ni la vérité révélée !
Nombreuses variantes ou extensions :
- Piles multi-protocolaires (par ex. : UDP/TCP)
- Notion de sous-couches (par ex. : PMD/PHY)
- Adaptation à l’évolution des techniques (réseaux locaux, ATM, RNIS, etc.)
- Interconnexion de réseaux issus de familles protocolaires différentes
Le modèle est cependant pratique pour avoir un langage commun et fournir un repère.
- par ex. : service /protocole, SDU/PDU, multiplexage/segmentation
Nous allons explorer les différentes couches (de bas en haut) en étudiant leurs protocoles, leurs
fonctions, leurs mécanismes et le format des objets qu’elles échangent.
s Architecture générale s
____
B. Cousin et C. Viho - © IFSIC -Université Rennes I 124
7. Quelques commentaires
Note 1 : les normes ont une durée de vie limitée
- Elles naissent, elles vivent, elles meurent !
- ex : IPv4 -- IPv6
Note 2 : une norme répond à des besoins spécifiques
- Une réponse à un problème, à un instant !
- ex : HDLC n’est pas parfaitement adapté aux réseaux locaux
Note 3 : les normes spécifient juste ce qu’il faut
- Ce n’est pas un dossier de conception
- Notamment, les normes protocolaires spécifient le comportement des systèmes ouverts
dans leurs échanges avec les autres systèmes, mais pas leur fonctionnement interne et pro-
pre.
- ex : un langage est défini par sa syntaxe et ses règles opératoires, mais pas par l’implanta-
tion de son compilateur !
- ex : de même un protocole informatique est défini par le format de ses messages, la procé-
dure qui régit ces messages (le protocole) et son service, mais pas par une de ses implanta-
tions.
s Architecture générale s
____
B. Cousin et C. Viho - © IFSIC -Université Rennes I 125
Note 4 : Un concept est abstrait
- Les concepts introduits pour décrire les systèmes ouverts constituent une abstraction, en
dépit de similitude avec les objets du monde réel :
- Parfois une nouvelle terminologie spécifique est introduite qui masque l’objet réel
. peut rendre difficile l’appréhension du concept.
. ex : N-PDU (“Network layer Protocol Data Unit”) == datagramme ou paquet
- Parfois une terminologie usuelle est utilisée qui fait référence (trop) clairement à l’objet réel
. peut rendre difficile l’abstraction ou entraîne une certaine confusion
. ex : connexion
Note 5 : Le modèle OSI ne doit pas être un dogme
- Il n’est pas nécessaire que les systèmes soient implantés suivant la description du modèle de
référence
- Le système n’est pas forcément organisé en 7 modules ou tâches assurant chacune les fonc-
tions de l’une des 7 couches !
- Le modèle doit s’adapter au cours du temps aux inovations :
. les bons concepts, les bonnes techniques perdurent naturellement
s Architecture générale s
____
B. Cousin et C. Viho - © IFSIC -Université Rennes I 126
Note 6:
- Une couche peut exister et être vide car une couche peut regrouper un ensemble de fonc-
tions qui ne sont pas mises en oeuvre !
- Dans ce dernier cas, soit le service n’est pas nécessaire à la couche supérieure, soit il est
déjà rendu par la couche inférieure.
Note 7 :
- Le domaine de normalisation de l’OSI est restreint aux problèmes soulevés par la commu-
nication des données entre applications informatiques distantes.
. Ce n’est pas le domaine des traitements locaux spécifiques à ces applications tel que les
techniques d’utilisation des ressources locales : gestion locale de fichiers, partage du
processeur, synchronisation locale des tâches, accès aux données locales, etc.

Más contenido relacionado

La actualidad más candente

Chapitre 4: Architecture simplifiée d’un ordinateur
Chapitre 4: Architecture simplifiée d’un ordinateur Chapitre 4: Architecture simplifiée d’un ordinateur
Chapitre 4: Architecture simplifiée d’un ordinateur Mohamed Lahby
 
Cha1 introduction
Cha1 introductionCha1 introduction
Cha1 introductionEns Kouba
 
Cours r _seaux_chap1et2
Cours r _seaux_chap1et2Cours r _seaux_chap1et2
Cours r _seaux_chap1et2Amel Morchdi
 
Cours r _seaux__chapitre_5
Cours r _seaux__chapitre_5Cours r _seaux__chapitre_5
Cours r _seaux__chapitre_5Amel Morchdi
 
Seance 1 intro+reseaux
Seance 1 intro+reseauxSeance 1 intro+reseaux
Seance 1 intro+reseauxENS
 
(équipements réseau)
(équipements réseau)(équipements réseau)
(équipements réseau)Anouar Abtoy
 
Introduction au reseau
Introduction au  reseauIntroduction au  reseau
Introduction au reseauHamza Nsiri
 
Chapitre 3 - Commutation dans les LANs
Chapitre 3 - Commutation dans les LANsChapitre 3 - Commutation dans les LANs
Chapitre 3 - Commutation dans les LANsTarik Zakaria Benmerar
 

La actualidad más candente (14)

Reseau
ReseauReseau
Reseau
 
Lecours
LecoursLecours
Lecours
 
Chapitre 4: Architecture simplifiée d’un ordinateur
Chapitre 4: Architecture simplifiée d’un ordinateur Chapitre 4: Architecture simplifiée d’un ordinateur
Chapitre 4: Architecture simplifiée d’un ordinateur
 
(services)
(services)(services)
(services)
 
Cha1 introduction
Cha1 introductionCha1 introduction
Cha1 introduction
 
Cours r _seaux_chap1et2
Cours r _seaux_chap1et2Cours r _seaux_chap1et2
Cours r _seaux_chap1et2
 
Cours r _seaux__chapitre_5
Cours r _seaux__chapitre_5Cours r _seaux__chapitre_5
Cours r _seaux__chapitre_5
 
Archi reseaux
Archi reseauxArchi reseaux
Archi reseaux
 
Vhdl
VhdlVhdl
Vhdl
 
Seance 1 intro+reseaux
Seance 1 intro+reseauxSeance 1 intro+reseaux
Seance 1 intro+reseaux
 
(équipements réseau)
(équipements réseau)(équipements réseau)
(équipements réseau)
 
Chapitre 2 - Réseaux locaux
Chapitre 2 - Réseaux locauxChapitre 2 - Réseaux locaux
Chapitre 2 - Réseaux locaux
 
Introduction au reseau
Introduction au  reseauIntroduction au  reseau
Introduction au reseau
 
Chapitre 3 - Commutation dans les LANs
Chapitre 3 - Commutation dans les LANsChapitre 3 - Commutation dans les LANs
Chapitre 3 - Commutation dans les LANs
 

Destacado

Génie Logiciels : Introduction aux architectures
Génie Logiciels : Introduction aux architecturesGénie Logiciels : Introduction aux architectures
Génie Logiciels : Introduction aux architecturesMohammed Amine Mostefai
 
Realite augmentee
Realite augmenteeRealite augmentee
Realite augmenteeFree Lance
 
Allocation de chômage en Polynésie Présentation (2)
Allocation de chômage en Polynésie Présentation (2)Allocation de chômage en Polynésie Présentation (2)
Allocation de chômage en Polynésie Présentation (2)COLLECTIF CHÔMEURS EN ACTION
 
Document
DocumentDocument
DocumentViewOn
 
World Passion Journal interne
World Passion Journal interne World Passion Journal interne
World Passion Journal interne World-Passion
 
Document
DocumentDocument
DocumentViewOn
 
Optimizando Algoritmos Evolutivos - MAEB
Optimizando Algoritmos Evolutivos - MAEBOptimizando Algoritmos Evolutivos - MAEB
Optimizando Algoritmos Evolutivos - MAEBJuan J. Merelo
 
Présentation Soirée Grands Crus de Bordeaux
Présentation Soirée Grands Crus de BordeauxPrésentation Soirée Grands Crus de Bordeaux
Présentation Soirée Grands Crus de Bordeauxepf_oenologie
 
1ère Infolettre de l'AQIA
1ère Infolettre de l'AQIA1ère Infolettre de l'AQIA
1ère Infolettre de l'AQIAJulie Jean
 
Eb présentation fév. 2010 injectables
Eb présentation fév. 2010  injectablesEb présentation fév. 2010  injectables
Eb présentation fév. 2010 injectablesElise Bernier
 
Veille16.08.2010
Veille16.08.2010Veille16.08.2010
Veille16.08.2010Agence Elan
 
un Nord-Pas de Calais autonome et résilient
un Nord-Pas de Calais autonome et résilientun Nord-Pas de Calais autonome et résilient
un Nord-Pas de Calais autonome et résilientNordPasdeCalais
 
Séance n°5 positionnement
Séance n°5   positionnementSéance n°5   positionnement
Séance n°5 positionnementMeneur de Jeu
 
Diaporama du show room(1)
Diaporama du show room(1)Diaporama du show room(1)
Diaporama du show room(1)Yann Mar
 
Fenómenos paranormales (1)
Fenómenos paranormales (1)Fenómenos paranormales (1)
Fenómenos paranormales (1)Nicol Rueda
 
Le superviseur et le y extrait 2014
Le superviseur et le y extrait 2014Le superviseur et le y extrait 2014
Le superviseur et le y extrait 2014Claude Munger
 

Destacado (20)

Génie Logiciels : Introduction aux architectures
Génie Logiciels : Introduction aux architecturesGénie Logiciels : Introduction aux architectures
Génie Logiciels : Introduction aux architectures
 
Realite augmentee
Realite augmenteeRealite augmentee
Realite augmentee
 
Allocation de chômage en Polynésie Présentation (2)
Allocation de chômage en Polynésie Présentation (2)Allocation de chômage en Polynésie Présentation (2)
Allocation de chômage en Polynésie Présentation (2)
 
Feuilles de platane
Feuilles de plataneFeuilles de platane
Feuilles de platane
 
Document
DocumentDocument
Document
 
World Passion Journal interne
World Passion Journal interne World Passion Journal interne
World Passion Journal interne
 
Document
DocumentDocument
Document
 
Optimizando Algoritmos Evolutivos - MAEB
Optimizando Algoritmos Evolutivos - MAEBOptimizando Algoritmos Evolutivos - MAEB
Optimizando Algoritmos Evolutivos - MAEB
 
Présentation Soirée Grands Crus de Bordeaux
Présentation Soirée Grands Crus de BordeauxPrésentation Soirée Grands Crus de Bordeaux
Présentation Soirée Grands Crus de Bordeaux
 
Narcotráfico y el consumo de drogas
Narcotráfico y el consumo de drogasNarcotráfico y el consumo de drogas
Narcotráfico y el consumo de drogas
 
1ère Infolettre de l'AQIA
1ère Infolettre de l'AQIA1ère Infolettre de l'AQIA
1ère Infolettre de l'AQIA
 
Eb présentation fév. 2010 injectables
Eb présentation fév. 2010  injectablesEb présentation fév. 2010  injectables
Eb présentation fév. 2010 injectables
 
Veille16.08.2010
Veille16.08.2010Veille16.08.2010
Veille16.08.2010
 
un Nord-Pas de Calais autonome et résilient
un Nord-Pas de Calais autonome et résilientun Nord-Pas de Calais autonome et résilient
un Nord-Pas de Calais autonome et résilient
 
Séance n°5 positionnement
Séance n°5   positionnementSéance n°5   positionnement
Séance n°5 positionnement
 
Diaporama du show room(1)
Diaporama du show room(1)Diaporama du show room(1)
Diaporama du show room(1)
 
Vino
VinoVino
Vino
 
Fenómenos paranormales (1)
Fenómenos paranormales (1)Fenómenos paranormales (1)
Fenómenos paranormales (1)
 
EDFU 3007
EDFU 3007EDFU 3007
EDFU 3007
 
Le superviseur et le y extrait 2014
Le superviseur et le y extrait 2014Le superviseur et le y extrait 2014
Le superviseur et le y extrait 2014
 

Similar a Cours informatique 12

partie osi ( open system inerconnexion);
partie osi ( open system inerconnexion);partie osi ( open system inerconnexion);
partie osi ( open system inerconnexion);kawtarelbiraki
 
LES RESEAUX INFORMATIQUES.pdf
LES RESEAUX INFORMATIQUES.pdfLES RESEAUX INFORMATIQUES.pdf
LES RESEAUX INFORMATIQUES.pdfssuser18776b
 
416769859360_chap2fondementdesreseaux2023.pdf
416769859360_chap2fondementdesreseaux2023.pdf416769859360_chap2fondementdesreseaux2023.pdf
416769859360_chap2fondementdesreseaux2023.pdfRihabBENLAMINE
 
Ch2_Les modèles OSI et TCP_IP.pptx
Ch2_Les modèles OSI et TCP_IP.pptxCh2_Les modèles OSI et TCP_IP.pptx
Ch2_Les modèles OSI et TCP_IP.pptxOthmaneMansouri1
 
Administration Reseau
Administration ReseauAdministration Reseau
Administration Reseaudenischef1
 
Alphorm.com Formation CCNA 200-301 version 2020 (1of6) : Les Fondamentaux des...
Alphorm.com Formation CCNA 200-301 version 2020 (1of6) : Les Fondamentaux des...Alphorm.com Formation CCNA 200-301 version 2020 (1of6) : Les Fondamentaux des...
Alphorm.com Formation CCNA 200-301 version 2020 (1of6) : Les Fondamentaux des...Alphorm
 
Couche1 couche2 s4_v05
Couche1 couche2 s4_v05Couche1 couche2 s4_v05
Couche1 couche2 s4_v05LeslyOctave
 
Coursrseaux 111019081618-phpapp01
Coursrseaux 111019081618-phpapp01Coursrseaux 111019081618-phpapp01
Coursrseaux 111019081618-phpapp01Fabrice Enock
 
Le model OSI.pptx
Le model OSI.pptxLe model OSI.pptx
Le model OSI.pptxxxBMAxx1
 
ADMINISTRATION SYST ME ET R SEAUX
ADMINISTRATION SYST ME ET R SEAUXADMINISTRATION SYST ME ET R SEAUX
ADMINISTRATION SYST ME ET R SEAUXMonica Waters
 
Programmation réseau en JAVA
Programmation réseau en JAVAProgrammation réseau en JAVA
Programmation réseau en JAVABachir Benyammi
 
Réseau local sous windows 2003 server
Réseau local sous windows 2003 serverRéseau local sous windows 2003 server
Réseau local sous windows 2003 serverOussama BenGharbi
 
ITN_Module_6.pptx
ITN_Module_6.pptxITN_Module_6.pptx
ITN_Module_6.pptxserieux1
 

Similar a Cours informatique 12 (20)

partie osi ( open system inerconnexion);
partie osi ( open system inerconnexion);partie osi ( open system inerconnexion);
partie osi ( open system inerconnexion);
 
01 tcpip
01 tcpip01 tcpip
01 tcpip
 
Cours s5 réseau FSO
Cours s5 réseau FSOCours s5 réseau FSO
Cours s5 réseau FSO
 
Smi5 cours partie1
Smi5 cours partie1Smi5 cours partie1
Smi5 cours partie1
 
LES RESEAUX INFORMATIQUES.pdf
LES RESEAUX INFORMATIQUES.pdfLES RESEAUX INFORMATIQUES.pdf
LES RESEAUX INFORMATIQUES.pdf
 
416769859360_chap2fondementdesreseaux2023.pdf
416769859360_chap2fondementdesreseaux2023.pdf416769859360_chap2fondementdesreseaux2023.pdf
416769859360_chap2fondementdesreseaux2023.pdf
 
Ch2_Les modèles OSI et TCP_IP.pptx
Ch2_Les modèles OSI et TCP_IP.pptxCh2_Les modèles OSI et TCP_IP.pptx
Ch2_Les modèles OSI et TCP_IP.pptx
 
Administration Reseau
Administration ReseauAdministration Reseau
Administration Reseau
 
Alphorm.com Formation CCNA 200-301 version 2020 (1of6) : Les Fondamentaux des...
Alphorm.com Formation CCNA 200-301 version 2020 (1of6) : Les Fondamentaux des...Alphorm.com Formation CCNA 200-301 version 2020 (1of6) : Les Fondamentaux des...
Alphorm.com Formation CCNA 200-301 version 2020 (1of6) : Les Fondamentaux des...
 
Couche1 couche2 s4_v05
Couche1 couche2 s4_v05Couche1 couche2 s4_v05
Couche1 couche2 s4_v05
 
Coursrseaux 111019081618-phpapp01
Coursrseaux 111019081618-phpapp01Coursrseaux 111019081618-phpapp01
Coursrseaux 111019081618-phpapp01
 
Cours réseaux
Cours réseauxCours réseaux
Cours réseaux
 
Le model OSI.pptx
Le model OSI.pptxLe model OSI.pptx
Le model OSI.pptx
 
ADMINISTRATION SYST ME ET R SEAUX
ADMINISTRATION SYST ME ET R SEAUXADMINISTRATION SYST ME ET R SEAUX
ADMINISTRATION SYST ME ET R SEAUX
 
Programmation réseau en JAVA
Programmation réseau en JAVAProgrammation réseau en JAVA
Programmation réseau en JAVA
 
Réseau local sous windows 2003 server
Réseau local sous windows 2003 serverRéseau local sous windows 2003 server
Réseau local sous windows 2003 server
 
Chp3 - ESB
Chp3 - ESBChp3 - ESB
Chp3 - ESB
 
ITN_Module_6.pptx
ITN_Module_6.pptxITN_Module_6.pptx
ITN_Module_6.pptx
 
Petals DSB - Current Status
Petals DSB - Current StatusPetals DSB - Current Status
Petals DSB - Current Status
 
Tiny os_2
Tiny os_2Tiny os_2
Tiny os_2
 

Cours informatique 12

  • 1. s Architecture générale s ____ B. Cousin et C. Viho - © IFSIC -Université Rennes I 94 Chapitre 4 : Architecture générale des réseaux informatiques /udd/bcousin/Pages-web-Armor/Enseignement/Reseaux-generalites/Cours/4.recover.fm - 1 juin 2001 18:28 Plan - 1. Introduction p95 - 2. Le modèle de référence OSI de l’ISO p98 - 3. Quelques fonctions p112 - 4. Autres exemples d’architecture de réseaux p118 - 5. Normalisation des réseaux p120 - 6. Conclusion p123 - 7. Quelques commentaires p124s Bibliographie - Reference model for open systems interconnection : ISO 7498, UIT-T.200 - G. Pujolle, Les réseaux, Eyrolles, 1995. Chapitre 3. - H. Nussbaumer, Téléinformatique, Presses Polytechniques romandes, 1987. Chapitre 1.3. - A.Tanenbaum, Réseaux, 3ème éd., InterEditions, 1997. Chapitre 1.
  • 2. s Architecture générale s ____ B. Cousin et C. Viho - © IFSIC -Université Rennes I 95 1. Introduction Les réseaux informatiques doivent permettre à des applications informatiques de coopérer sans avoir à tenir compte de l’hétérogénéité des moyens et procédés de transmission (par exemple : de la topologie, des méthodes d’accès, des caractéristiques des équipements ou des supports, etc.). . Adapter la technologie de transmission au support de communication . Masquer les phénomènes altérant la transmission . Maintenir la qualité demandée . Offrir l’interopérabilité (1) . Optimiser l’utilisation des ressources (2) . Assurer la pérennité des choix (3) (1) + (2) + (3) ==> Normalisation SNA IBM DEC BULL DSA DECnet SNA/DECnet DSA/DECnet SNA/DSA OSI IBM DEC BULL OSI OSI
  • 3. s Architecture générale s ____ B. Cousin et C. Viho - © IFSIC -Université Rennes I 96 1.1. Objectif Réduire la complexité de conception des réseaux informatiques. Principes : - démarche analytique : recensement des fonctions nécessaires - démarche synthétique : classement des fonctions - démarche simplificatrice et constructive : . regroupement en sous-ensembles pour simplifier la compréhension des fonctions (fron- tières précises, concises et utiles) . décomposition hiérarchique de l’ensemble des mécanismes à mettre en œuvre en une série de couches (ou niveaux). Remarque : Le nombre de couches, leurs noms et leurs fonctions varient selon les types de réseaux Exemples : le modèle de référence de l’OSI : 7 couches LAN : 2 + 2 sous-couches; ATM : 2 + 1 + 3 sous-couches, Internet : 3 ou 4 couches
  • 4. s Architecture générale s ____ B. Cousin et C. Viho - © IFSIC -Université Rennes I 97 1.2. Principes de base de la décomposition en couches Une couche doit être créée lorsqu’un nouveau niveau d’abstraction est nécessaire Chaque couche exerce une fonction bien définie Les fonctions de chaque couche doivent être choisies en pensant à la définition des protocoles nor- malisés internationaux Le choix des frontières entre couches doit minimiser le flux d’informations aux interfaces Le nombre de couches doit être : - suffisamment grand pour éviter la cohabitation dans une même couche de fonctions très dif- férentes, et - suffisamment petit pour éviter que l’architecture ne devienne difficile à maîtriser.
  • 5. s Architecture générale s ____ B. Cousin et C. Viho - © IFSIC -Université Rennes I 98 2. Le modèle de référence OSI de l’ISO 2.1. Présentation Norme de description de l’architecture générale des réseaux informatiques: - L’OSI = “Open Systems Interconnection : reference model” - modèle en 7 couches Les noms de la norme : - ISO : IS 7498 - CCITT : X200 (nouvellement IUT-T) - AFNOR : NF.Z.70.001
  • 6. s Architecture générale s ____ B. Cousin et C. Viho - © IFSIC -Université Rennes I 99 2.2. Notion de couche, de protocole et de service Une couche est spécialisée dans un ensemble de fonctions particulières. Elle utilise les fonction- nalités de la couche inférieure et propose ses fonctionnalités à la couche supérieure. Un système est un ensemble de composants formant un tout autonome. Une entité est l’élément actif d’une couche dans un système. - entités homologues (paires) : entités de même couche situées dans des systèmes distants Le protocole d’une couche N définit l’ensemble des règles ainsi que les formats et la signification des objets échangés, qui régissent la communication entre les entités de la couche N. Le service d’une couche N définit l’ensemble des fonctionnalités possédées par la couche N et fournies aux entités de la couche N+1 à l’interface N/N+1. Notation : on note N_X (ou encore X(N)) l’objet de type X appartenant à la couche N. - ex : N-entité ou entité(N)
  • 7. s Architecture générale s ____ B. Cousin et C. Viho - © IFSIC -Université Rennes I 100 L’architecture d’un réseau est définie par l’ensemble des couches et la description des protocoles et des services de chacune d’elles. Couche (N) Couche (N+1) Couche (N-1) entité A entité B InterfacesProtocole de couche N d’accès au service Service de la couche N Service de la couche N-1 Système A Système B
  • 8. s Architecture générale s ____ B. Cousin et C. Viho - © IFSIC -Université Rennes I 101 2.3. Architecture générale du modèle OSI Le modèle OSI possède sept couches Le modèle décrit simplement ce que chaque couche doit réaliser (le service), les règles et le format des échanges (le protocole), mais pas leur implantation. Physique Couches Liaison de données Réseau Transport Session Présentation Application Nom des unités de données échangées A-PDU P-PDU S-PDU T-PDU/Message N-IPDU/Paquet L-PDU/Trame Bit Support physique d’interconnexion Protocole d’application Protocole de présentation Protocole de session Protocole de transport système intermédiaire CoucheshautesCouchesbasses système d’extrémité
  • 9. s Architecture générale s ____ B. Cousin et C. Viho - © IFSIC -Université Rennes I 102 2.4. Les sept couches du modèle OSI 2.4.1 La couche Physique (couche 1) Fournit les moyens mécaniques, optiques, électroniques, fonctionnels et procéduraux nécessaires à l’activation, au maintien et à la désactivation des connexions physiques nécessaires à la transmission de trains de bits. Note : les systèmes sont interconnectés réellement au moyen de supports physiques de communi- cation. Ces derniers ne font pas partie de la couche Physique. 2.4.2 La couche Liaison de données (couche 2) Assure la transmission d’informations entre (2 ou plusieurs) systèmes immédiatement adjacents. Détecte et corrige, dans la mesure du possible, les erreurs issues de la couche inférieure. Les objets échangés sont souvent appelés trames (“frames”). 2.4.3 La couche Réseau (couche 3) Achemine les informations à travers un réseau pouvant être constitué de systèmes intermédiaires (routeurs). Les objets échangés sont souvent appelés paquets (“packets”).
  • 10. s Architecture générale s ____ B. Cousin et C. Viho - © IFSIC -Université Rennes I 103 2.4.4 La couche Transport (couche 4) Assure une transmission de bout en bout des données. Maintient une certaine qualité de la trans- mission, notamment vis-à-vis de la fiabilité et de l’optimisation de l’utilisation des ressources. Les ob- jets échangés sont souvent appelés messages (de même pour les couches supérieures). 2.4.5 La couche Session (couche 5) Fournit aux entités coopérantes les moyens nécessaires pour synchroniser leurs dialogues, les in- terrompre ou les reprendre tout en assurant la cohérence des données échangées. 2.4.6 La couche Présentation (couche 6) Se charge de la représentation des informations que les entités s’échangent. Masque l’hétérogénéi- té de techniques de codage utilisées par les différents systèmes. 2.4.7 La couche Application (couche 7) Donne aux processus d’application les moyens d’accéder à l’environnement de communication de l’OSI. Comporte de nombreux protocoles adaptés aux différentes classes d’application. Note : les fonctionnalités locales des applications proprement dites sont hors du champ de l’OSI donc de la couche Application !
  • 11. s Architecture générale s ____ B. Cousin et C. Viho - © IFSIC -Université Rennes I 104 2.4.8 Conclusion Les trois premières couches constituent les couches basses où les contraintes du réseau sont per- ceptibles. Fonctions élémentaires spécialisées dans la transmission. La couche Transport est une couche charnière, d’adaptation ou intermédiaire, associée le plus sou- vent aux couches basses. Les trois dernières couches constituent les couches hautes où les contraintes de l’application sont perceptibles. Fonctions complexes et variables adaptées aux traitements applicatifs. Attention : La norme stipule clairement qu’il s’agit d’un modèle de référence et par conséquent, suivant le contexte dans lequel on se trouve et les besoins de communication, certaines fonctionnalités de certaines couches peuvent ne pas être utilisées (protocoles alternatifs, classes de protocole, options, etc.).
  • 12. s Architecture générale s ____ B. Cousin et C. Viho - © IFSIC -Université Rennes I 105 2.5. Connexion SAP(N) : “service access point” - point identifié où les services sont fournis par l’entité(N) à une entité(N+1) . ex : adresse Connexion(N) : association d’entités homologues pour le transfert de données - entités correspondantes : entités associées par la même connexion Extrémité de connexion(N) : terminaison d’une connexion(N) à un SAP(N). - connexion bipoint : connexion comportant exactement 2 extrémités. - connexion multipoint : connexion comportant plus de 2 extrémités. entité(N+1) entité(N) entité(N) SAP(N) entité(N+1) entité(N+1) SAP(N) connexion(N) entités correspondantescouche N+1 couche N Interface N
  • 13. s Architecture générale s ____ B. Cousin et C. Viho - © IFSIC -Université Rennes I 106 2.6. Les modes de communication On peut distinguer deux grands modes de communication: - communication en mode connecté (appelé aussi “with connection”) - communication en mode non connecté (appelé aussi “connectionless” ou par abus de lan- gage “datagramme”) 2.6.1 Le mode non connecté - 1 seule phase (ou 0!) : . le transfert de données - chaque unité de transfert de données est acheminée indépendamment - les entités communicantes ne mémorisent rien (“memoryless”). - les messages échangées sont auto-suffisants (“self-content”)
  • 14. s Architecture générale s ____ B. Cousin et C. Viho - © IFSIC -Université Rennes I 107 2.6.2 Le mode connecté - 3 phases : . phase d’établissement de la connexion . phase de transfert de données . phase de libération de la connexion - un contexte (réparti) est partagé par les membres de la connexion : . par exemple : le numéro du paquet - permet (facilite) le contrôle et la gestion du transfert de données : . contrôle d’erreur, contrôle de flux, maintien en séquence, etc. - les messages échangés comportent des informations qui ne sont utilisables que grâce à la connaissance de ce contexte : . par exemple : le numéro de paquet / la largeur de la fenêtre coulissante
  • 15. s Architecture générale s ____ B. Cousin et C. Viho - © IFSIC -Université Rennes I 108 2.7. Les primitives de service Le protocole(N) s’appuie sur le service(N-1), donc la description du service est nécessaire à la compréhension du protocole. Attention, le service n’est accessible qu’à l’intérieur d’un système : la façon d’accéder au service ne doit pas être normalisée ! Les primitives spécifient le service : - Ce sont des objets abstraits (puisque le service est abstrait !) - Echangées à travers un interface idéal (sans perte et sans délai) - Leur représentation ressemble à une procédure avec des paramètres . préfixe : l’initiale de la couche . suffixe : le type de primitive . Exemples : . T_Data.req(T_SDU) . LLC_Data.req(ad-locale, ad-distante, L_SDU, classe-de-service)
  • 16. s Architecture générale s ____ B. Cousin et C. Viho - © IFSIC -Université Rennes I 109 Il existe quatre types de primitives : - Request : Une entité sollicite un service - Indication : Une entité est informée d’une demande de service - Response : Une entité a rendu le service, si possible - Confirmation : Une entité est informée que le service a été rendu Par exemple : De très nombreuses variantes d’enchaînement des types de primitives de service [1 à 4] existent ! Service confirmé (Couche N)(Couche N+1) (Couche N+1) N-xxx.req(...) N-xxx.ind(...) Fournisseur du service N-xxx.resp(...) N-xxx.conf(...) Utilisateur du service A Utilisateur du service B Service non confirmé (Couche N)(Couche N+1) (Couche N+1) N-xxx.req(...) N-xxx.ind(...) Fournisseur du service Utilisateur du service A Utilisateur du service B Temps Temps
  • 17. s Architecture générale s ____ B. Cousin et C. Viho - © IFSIC -Université Rennes I 110 2.8. Les unités de données SDU(N) : - unité de données spécifique au service(N), dont l’intégrité est préservée d’une extrémité à l’autre d’une connexion. Mais pas forcément entre ! . potentiellement de taille quelconque. . exemple : un fichier à transmettre PDU(N) : - unité de données spécifique au protocole(N), adaptée à la transmission, constituée par les informations de contrôle du protocole (PCI(N)) et éventuellement par des portions de don- nées issues du SDU(N) . par ex. : une trame, un paquet.
  • 18. s Architecture générale s ____ B. Cousin et C. Viho - © IFSIC -Université Rennes I 111 IDU(N) : - unité d’information transférée en une seule interaction à l’interface de 2 couches, constituée d’information de contrôle d’interface (ICI(N)) et tout ou partie d’une SDU(N). . dépend du système d’accueil (notamment leur format). . dépendant de l’implantation . par ex. : les tampons (buffers) utilisés pour charger le fichier (N)PCI (N)SDU Couche N+1 Interface Couche N Les entités de couche N échangent des N-PDU par le protocole de la couche N (N+1)PDU (N)PDU (pas de segmentation ni de blocage)
  • 19. s Architecture générale s ____ B. Cousin et C. Viho - © IFSIC -Université Rennes I 112 3. Quelques fonctions Ces fonctions peuvent être présentes dans n’importe quelle couche. 3.1. Multiplexage/démultiplexage Fonction d’une couche(N) permettant de prendre en charge plusieurs connexions(N) sur une seule connexion(N-1) - Optimise l’utilisation de la connexion(N-1) - Permet l’établissement simultané de plusieurs connexions(N) alors qu’une seule con- nexion(N-1) existe - Problème : identification des connexions, contrôle des différents flux Exemple : multiplexage de plusieurs connexions de Transport sur une seule connexion de Réseau couche(N) N-connexions N-1-connexion
  • 20. s Architecture générale s ____ B. Cousin et C. Viho - © IFSIC -Université Rennes I 113 3.2. Eclatement/recombinaison Fonction d’une couche(N) permettant d’utiliser plusieurs connexions(N-1) pour prendre en charge une connexion(N). - Amélioration de la fiabilité grâce à la redondance - Amélioration des performances malgré l’usage de connexions(N-1) peu performantes - Problème : dé-séquencement - Appelé aussi multiplexage aval. Exemple : HDLC multiliaison (“multilink”) couche(N) N-connexion N-1-connexions
  • 21. s Architecture générale s ____ B. Cousin et C. Viho - © IFSIC -Université Rennes I 114 3.3. Segmentation/réassemblage Fonction d’une couche(N) mettant en correspondance une SDU(N) avec plusieurs PDU(N) - Adaptation de la taille des données (N-SDU) aux caractéristiques de transmission (N-PDU) - Problème : identification des PDU transportant les données constituant la SDU. Exemple : les fragments d’un datagramme IP (N)PCI Couche N+1 Interface Couche N (N)PDU (N)PDU (N)SDU
  • 22. s Architecture générale s ____ B. Cousin et C. Viho - © IFSIC -Université Rennes I 115 3.4. Groupage/dégroupage Fonction d’une couche(N) mettant en correspondance plusieurs SDU(N) avec une seule PDU(N) - Adaptation de la taille des données (N-SDU) aux caractéristiques de la transmission (N- PDU) - Diminution du surcoût (overhead) - Problème : identification des SDU transportées. Exemple : la “bufferisation” des données sous TCP (N)PCI Couche N+1 Interface Couche N (N)PDU (N)SDU (N)SDU
  • 23. s Architecture générale s ____ B. Cousin et C. Viho - © IFSIC -Université Rennes I 116 3.5. Concaténation/séparation Fonction d’une couche (N) mettant en correspondance plusieurs PDU(N) avec une seule SDU(N) - Adaptation de la taille des données aux caractéristiques du service (N-SDU) - Diminution du surcoût (overhead) - Problème : identification des PDU transportées Exemple : Concaténation des commandes et des données de la couche Transport. Couche N-1 Couche N (N-1)SDU (N)PDU (N)PDU
  • 24. s Architecture générale s ____ B. Cousin et C. Viho - © IFSIC -Université Rennes I 117 3.6. Transmission de données L’encapsulation : - Les données d’une couche sont encapsulées dans une unité de données de la couche infé- rieure. - Par ex. : la lettre dans l’enveloppe dans le sac postal dans le train postal. données Physique Liaison Réseau Transport Session Présentation Application Physique Liaison Réseau Transport Session Présentation Application message paquet trame processus émission processus réception donnéesAH PH SH TH NH DH DE signal codant le train de bits support de transmission systèmeA systèmeB
  • 25. s Architecture générale s ____ B. Cousin et C. Viho - © IFSIC -Université Rennes I 118 4. Autres exemples d’architecture de réseaux 4.1. Architecture des réseaux locaux couche Physique couche Liaison de données sous-couche MAC (Medium Access Control) sous-couche LLC (Logical Link Control) (Ethernet, Token Ring, Token Bus, FDDI, etc.) correspondance avec l’OSI sous-couche PMD Architecture des réseaux locaux couches supérieures sous-couche PHY
  • 26. s Architecture générale s ____ B. Cousin et C. Viho - © IFSIC -Université Rennes I 119 4.2. Architecture générale d’Internet couche Physique couche Liaison de données correspondance avec l’OSI Architecture du monde Internet couches applicatives couche Réseau couche Transport TCP Control Protocol) (Transmission UDP (User Datagram Protocol) IP (Internet Protocol) Toutes sortes de protocoles offrant l’équivalent des fonctionnalités des couches 1 et 2 du modèle OSI Les protocoles applicatifs d’Internet : telnet, ftp, http, smtp, dns, nfs, snmp, xdr, etc.
  • 27. s Architecture générale s ____ B. Cousin et C. Viho - © IFSIC -Université Rennes I 120 5. Normalisation des réseaux La normalisation garantit l’interfonctionnement et une certaine pérennité, diffusion ou efficacité ou de l’objet produit à partir de ces normes. 5.1. Les principaux organismes de normalisation, dans le domaine des réseaux numériques - ISO (International Standardization Organization) - IUT-T (International Union of Telecommunication - section Telecommunication) (ex- CCITT) - IEEE (Institute of Electrical and Electronic Engineers) - IETF / IRTF (Internet Engineering/Research Task Force) - ANSI, ECMA, AFNOR, etc. Différents types de protocoles Développement de nouvelles technologies Besoin croissant de communication Nécessité de définir des normes
  • 28. s Architecture générale s ____ B. Cousin et C. Viho - © IFSIC -Université Rennes I 121 5.2. Identification des normes et exemples de normes La dénomination d’une norme doit tenir compte d’un ensemble de critères : - son origine (ISO, IEEE, etc) - son domaine d’application (réseaux publics/privés/locaux/, téléphone, etc) - sa zone d’application (européenne, internationale, etc) Exemples de normes : Les normes ISO sont préfixées par IS (International Standard) . ISO/ IS 8208 (=X.25/L3), ISO / IS 8802.3 (=Ethernet), etc. Les normes IUT-T sont nommées à l’aide d’une lettre suivie d’un point et d’un numéro : . IUT-T / X.25, IUT-T / X.400 (Messagerie), IUT-T / V.24 (Jonction pour la transmission de données numériques sur lignes téléphoniques), etc. Les noms des normes IEEE : . IEEE 802.5 (Token Ring), etc. Les normes de l’IETF/IRTF sont appelées des RFC (“Request For Comments”) : . RFC 791 (Internet Protocol), RFC 768 (UDP), RFC 793 (TCP), …
  • 29. s Architecture générale s ____ B. Cousin et C. Viho - © IFSIC -Université Rennes I 122 5.3. Cycle de vie d’une norme Une norme est généralement développée au sein d’un groupe de travail ad hoc. - production de “draft” - expérimentation - la norme est généralement la (meilleure) réponse technique à un problème en fonction des connaissances de l’époque. Une norme est adoptée par des instances officielles - après un vote formel - la norme est publique et publiée - la norme répond a des compromis économiques … et politiques Une norme est généralement révisée : - périodiquement - une norme peut être écartée et même disparaître
  • 30. s Architecture générale s ____ B. Cousin et C. Viho - © IFSIC -Université Rennes I 123 6. Conclusion Modèle de référence pour l’interconnexion des systèmes informatiques hétérogènes : - en 7 couches (P, LdD, N, T, S, P, A) Mais ce ne doit pas être un dogme immuable, ni la vérité révélée ! Nombreuses variantes ou extensions : - Piles multi-protocolaires (par ex. : UDP/TCP) - Notion de sous-couches (par ex. : PMD/PHY) - Adaptation à l’évolution des techniques (réseaux locaux, ATM, RNIS, etc.) - Interconnexion de réseaux issus de familles protocolaires différentes Le modèle est cependant pratique pour avoir un langage commun et fournir un repère. - par ex. : service /protocole, SDU/PDU, multiplexage/segmentation Nous allons explorer les différentes couches (de bas en haut) en étudiant leurs protocoles, leurs fonctions, leurs mécanismes et le format des objets qu’elles échangent.
  • 31. s Architecture générale s ____ B. Cousin et C. Viho - © IFSIC -Université Rennes I 124 7. Quelques commentaires Note 1 : les normes ont une durée de vie limitée - Elles naissent, elles vivent, elles meurent ! - ex : IPv4 -- IPv6 Note 2 : une norme répond à des besoins spécifiques - Une réponse à un problème, à un instant ! - ex : HDLC n’est pas parfaitement adapté aux réseaux locaux Note 3 : les normes spécifient juste ce qu’il faut - Ce n’est pas un dossier de conception - Notamment, les normes protocolaires spécifient le comportement des systèmes ouverts dans leurs échanges avec les autres systèmes, mais pas leur fonctionnement interne et pro- pre. - ex : un langage est défini par sa syntaxe et ses règles opératoires, mais pas par l’implanta- tion de son compilateur ! - ex : de même un protocole informatique est défini par le format de ses messages, la procé- dure qui régit ces messages (le protocole) et son service, mais pas par une de ses implanta- tions.
  • 32. s Architecture générale s ____ B. Cousin et C. Viho - © IFSIC -Université Rennes I 125 Note 4 : Un concept est abstrait - Les concepts introduits pour décrire les systèmes ouverts constituent une abstraction, en dépit de similitude avec les objets du monde réel : - Parfois une nouvelle terminologie spécifique est introduite qui masque l’objet réel . peut rendre difficile l’appréhension du concept. . ex : N-PDU (“Network layer Protocol Data Unit”) == datagramme ou paquet - Parfois une terminologie usuelle est utilisée qui fait référence (trop) clairement à l’objet réel . peut rendre difficile l’abstraction ou entraîne une certaine confusion . ex : connexion Note 5 : Le modèle OSI ne doit pas être un dogme - Il n’est pas nécessaire que les systèmes soient implantés suivant la description du modèle de référence - Le système n’est pas forcément organisé en 7 modules ou tâches assurant chacune les fonc- tions de l’une des 7 couches ! - Le modèle doit s’adapter au cours du temps aux inovations : . les bons concepts, les bonnes techniques perdurent naturellement
  • 33. s Architecture générale s ____ B. Cousin et C. Viho - © IFSIC -Université Rennes I 126 Note 6: - Une couche peut exister et être vide car une couche peut regrouper un ensemble de fonc- tions qui ne sont pas mises en oeuvre ! - Dans ce dernier cas, soit le service n’est pas nécessaire à la couche supérieure, soit il est déjà rendu par la couche inférieure. Note 7 : - Le domaine de normalisation de l’OSI est restreint aux problèmes soulevés par la commu- nication des données entre applications informatiques distantes. . Ce n’est pas le domaine des traitements locaux spécifiques à ces applications tel que les techniques d’utilisation des ressources locales : gestion locale de fichiers, partage du processeur, synchronisation locale des tâches, accès aux données locales, etc.