Vous êtes sur la page 1sur 268

NTway.

com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

ARCHITECTURE ET PROTOCOLES TCP-IP


VISION APPROFONDIE
- Analyse Technique et Stratégique -

p1
PROTOCOLES TCP-IP VISION APPROFONDIE
SOMMAIRE

NTway.com J 1 - RAPPELS
Q Modèle OSI rôle et principes
p. 6
p. 7
Tél: 0-22-22-50-98 Q Rappel de vocabulaire p. 14
E-mail: ntway@iam.net.ma

J 2 - HISTORIQUE ET EVOLUTION p. 27
Q Internet en quelques dates p. 28
Q Evolution p. 32

J 3 - LES COUCHES 1 ET 2 DANS L'ARCHITECTURE TCP-IP p. 47


Q Principe général p . 49
Q Le cas particulier des réseaux locaux p. 51
J L'adressage de niveau MAC p. 51
J La structure de la couche 2 p. 54
J La méthode d'accès au support CSMA/CD p. 58
J La détection des erreurs p. 65
J La structure des MAC PDU p. 65
J La gestion du padding p. 66
J Les couches LLC de l'ISO p. 70
J La cohabitation Ethernet DIX et ISO 8802.3 p. 73
J Le rôle du SNAP p. 75
J Conclusion : les différents empilements TCP-IP sur LAN p. 77
Q Le cas particulier des WAN p. 78
J IP sur PPP (RFC 1171) p. 79
J IP sur SLIP (RFC 1055) p. 85
J IP sur HDLC p. 88
J IP sur Frame Relay p. 90
J IP, ATM et ADSL p. 94
J Evolution des architectures Telecom p. 95
Q Les VPN p. 96

J 4 - ADRESSAGE IP p. 97
Q Principe général p. 98
Q Les classes d'adressage IP p. 99
Q Les adresses IP réservées p. 102
Q Le subnetting p. 103
Q L'adressage privé e t la translation d'adresse p. 107
Q Modélisation du routage p. 111
Q Exercices sur le routage p. 116

p2
PROTOCOLES TCP-IP VISION APPROFONDIE
SOMMAIRE

NTway.com J 5 - LE PROTOCOLE ARP/RARP


Q Objectif du protocole
p. 117
p. 118
Tél: 0-22-22-50-98 Q Codage du protocole p. 126
E-mail: ntway@iam.net.ma
Q Relations avec l'ISO p. 129

J 6 - LE PROTOCOLE IP p. 130
Q Objectifs p. 131
Q Caractéristiques p. 132
Q Eléments protocolaires p. 133
Q Analyse des différents champs p. 134
Q IP sur X25 p. 164

J 7 - LE PROTOCOLE ICMP (Internet Control Message Protocol) p. 169


Q Objectifs du protocole p. 170
Q Éléments protocolaires p. 170

J 8 - L'ADRESSAGE DE NIVEAU 4 p. 184


Q Adressage OSI p. 185
Q Adressage TCP-IP p. 187

J 9 - LE PROTOCOLE UDP (User Data Protocol) p. 193


Q Objectifs p. 194
Q Eléments protocolaires p. 195
Q Codage des datagrammes UDP p. 197

J 10 - LE PROTOCOLE TCP (Transmission Control Protocol) p. 200


Q Objectifs p. 201
Q Eléments protocolaires p. 203
Q Codage des segments TCP p. 231
Q Encapsulation de X25 sur TCP (XOT) p. 239

p3
PROTOCOLES TCP-IP VISION APPROFONDIE
SOMMAIRE

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma J 11 - LE PROTOCOLE SNMP p. 241
Q Objectifs p. 242
Q Principe général p. 243
Q Les relations avec l'administration OSI p. 245
Q Le protocole SNMP p. 247
Q La sécurité des échanges protocolaires p. 252
Q Les MIB p. 256

J 12 - IP VERSION 6 p. 265

p4
NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

-1-
RAPPELS

p5
PROTOCOLES TCP-IP VISION APPROFONDIE
RAPPELS

NTway.com J Modèle OSI, rôle et principes


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Q Lorsque deux systèmes informatiques veulent s'échanger des données, c'est à dire
communiquer, il leur faut à l'évidence régler un grand nombre de problèmes, de nature
extrêmement différentes :

J choix d'un support


J raccordement au support
J fiabilité, détection des erreurs de ligne
J correction des erreurs de ligne
J contrôle de flux
J routage
J gestion des tours de parole et des resynchronisations de dialogues
J gestion des adaptations de codage d'information
J ...

Q En informatique, pour régler des problèmes, il faut programmer. Cette programmation


peur être anarchique ou, mieux, structurée. Il en est de même pour l'organisation des
communications.

Q Dans ce dernier cas, cependant, structurer n'est pas suffisant car il faut que les deux
machines communicantes structurent de façons identiques, d'où la nécessité d'une
normalisation de la façon de régler les différents problèmes concernés.

p6
PROTOCOLES TCP-IP VISION APPROFONDIE
RAPPELS

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
LE MODELE OSI EN 7 COUCHES

7 application application

6 présentation présentation

5 session session

4 transport transport

inter-réseaux inter-réseaux inter-réseaux


3
sous-réseau sous-réseau sous-réseau sous-réseau

LLC ou protocole LLC LLC LLC ou protocole


2
MAC ou enveloppe MAC MAC MAC ou enveloppe

codage codage codage codage


1
modulation modulation modulation modulation

0 support 0 support

f05-103

p7
PROTOCOLES TCP-IP VISION APPROFONDIE
RAPPELS

NTway.com Q Cette normalisation a conduit à définir de manière arbitraire 7 niveaux indépendants de


Tél: 0-22-22-50-98 fonctionnalités, chargés chacun d'un ensemble de problèmes bien précis : les sept
E-mail: ntway@iam.net.ma
couches de l'architecture ISO :

J Définition d'une couche.

Q Une couche n peut être considérée comme la résolution d'une famille de problèmes de
niveau n et a trois fonctions :

J utiliser si nécessaire les services de la couche n-1

J résoudre une famille de problèmes de niveau n en établissant un dialogue avec la couche n d'en
face : la couche homologue

J rendre un service à la couche n+1, la résolution du problème de niveau n

J Couche 1 ; couche physique.

Q Cette couche est chargée de véhiculer les éléments binaires d'un bout à l'autre du support
physique. Elle adapte donc le signal binaire au support. Pour cela, elle commence par
coder, c'est à dire affecter un signal électrique numérique à une suite d'informations
binaires, puis, si nécessaire, elle module, c'est à dire elle adapte la bande passante du
signal à celle du support.

p8
PROTOCOLES TCP-IP VISION APPROFONDIE
RAPPELS

NTway.com J Couche 2 ; couche liaison de données.


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Q Cette couche est divisée en deux sous-couches, appelées différemment suivant si on se


situe dans le monde des LAN (Local Area Network) ou le monde des WAN (Wide Area
Network).

Q En environnement LAN :

Q La sous-couche MAC (Medium Access Control) s'occupe de :

J gérer les problèmes d'accès au support physique,


J détecter les erreurs de transmission,
J identifier une machine sur le réseau.

Q La sous-couche LLC (Logical Link Control) s'occupe de :

J corriger éventuellement les erreurs détectées par la sous-couche MAC,


J identifier la couche utilisatrice.

Q En environnement WAN :

Q La sous-couche Enveloppe délimite les DLPDU et détecte les erreurs sur les DLPDU.

Q La sous-couche Protocole atténue les défauts de la couche 1 et corrige les erreurs.

p9
PROTOCOLES TCP-IP VISION APPROFONDIE
RAPPELS

NTway.com J Couche 3 ; couche réseau.


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Q Cette couche gère la mise bout à bout de supports physiques (habillés par les couches 1
et 2) de façon à mettre en relation les correspondants n'ayant pas de liaison directe entre
eux. Elle assure essentiellement les fonctions de routage, de mise bout à bout, de
multiplexage et de contrôle de flux.

J Couche 4 ; couche transport.

Q Cette couche est chargée de régler définitivement tous les problèmes relevant du
déplacement d'information et qui n'auraient pas été réglés par les couches inférieures.
Elle offre une vision de bout en bout du dialogue et doit assurer l'intégrité des données de
bout en bout. Si les couches 2 et 3 n'assurent pas correctement leurs fonctions, la couche
4 peut être amenée à avoir des fonctionnalités de couche 2 et/ou de couche 3.

J Couche 5 ; couche session.

Q Cette couche ne gère plus aucun problème de déplacement d'information, mais elle
s'occupe de l'organisation du dialogue entre les deux entités communicantes. Elle est
aussi capable de véhiculer des mécanismes d'identification ou de choix de parole. Elle
offre tous les outils aux couches 6/7 pour régler tous les problèmes d'intendance
organisationnels du dialogue.

p10
PROTOCOLES TCP-IP VISION APPROFONDIE
RAPPELS

NTway.com J Couche 6 ; couche présentation.


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Q Cette couche gère les problèmes de présentation des données, c'est à dire de syntaxe et
de forme. Elle définit la façon dont les deux entités communicantes peuvent se décrire
mutuellement le type de la donnée qu'elles s'échangent et l'encodage qu'elles ont adopté
pour représenter cette donnée sous forme d'une chaîne de bits. Pour cela, elles négocient
une syntaxe de transfert commune qui doit avoir une identification unique, et elles
utilisent un langage de description de données permettant de décrire les données
indépendamment de leur encodage.

J Couche 7 ; couche application.

Q Cette couche gère les différentes utilisations possibles des autres couches et elle
comprend un grand nombre d'éléments de services normalisés pouvant s'utiliser les uns
les autres (ACSE, CCRSE, ROSE, DSE, RTSE, ...).

p11
PROTOCOLES TCP-IP VISION APPROFONDIE
RAPPELS

NTway.com J Remarque sur les couches basses :


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Q Les couches basses sont en général subdivisées en terme de fonctions :

Q La couche 1 comprendra deux parties :

J modulation : adaptation du signal électrique au support physique,


J codage : transformation d'une suite de 0 et de 1 en un signal électrique numérique.

Q La couche 2 comprendra également deux parties :


J accès au support, enveloppe de trame et détection d'erreur,
J correction d'erreur et adressage des SAP.

Q La couche 3 comprendra également deux parties :


J sous-réseau et inter-réseau.

p12
PROTOCOLES TCP-IP VISION APPROFONDIE
RAPPELS
Rappels de vocabulaire.
NTway.com J

Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Q Service
J Chaque couche utilise la couche inférieure par le biais d'une interface normalisée (au sens
fonctionnalité et paramètres, mais pas, bien sûr, au sens implémentation).

J Chaque couche offre à la couche supérieure une interface normalisée : son service.

J Ainsi, il existe un service physique (avis V24 du CCITT, par exemple), mais aussi un service de
transport et un service de session.

Q SDU
J L'unité de donnée échangée dans l'interface de service (invisible par conséquent sur une ligne de
transmissions de données) s'appelle un Service Data Unit (SDU) :

Q Les 1-SDU, ou PhySDU sont les bits ;

Q Les 2-SDU, ou DLSDU sont les paquets ;

Q Les 3-SDU, ou NSDU n'ont pas de noms particuliers ;

Q Les 4-SDU, ou TSDU n'ont pas de noms particuliers ;

Q Les 5-SDU, ou SSDU n'ont pas de noms particuliers ;

Q Les 6-SDU, ou PSDU n'ont pas de noms particuliers ;

Q Les 7-SDU, ou ASDU n'ont pas de noms particuliers ;


p13
PROTOCOLES TCP-IP VISION APPROFONDIE
RAPPELS

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

PDU et SDU

N+1
dialogue de service :
définition des objectifs
n SAP fonctionnels mais pas
n SDU d'adressage, d'automate
ni de structure binaire

N
n SDU
dialogue horizontal : protocole
n PDU entièrement défini : adressage,
structure binaire et automate

n - 1 SDU

n - 1 SAP

N-1

F14-084

p14
PROTOCOLES TCP-IP VISION APPROFONDIE
RAPPELS

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
LA SEGMENTATION

N+1

n SAP
n SDU

N
n SDU

n PDU n PDU

n - 1 SAP

N-1

F14-085

p15
PROTOCOLES TCP-IP VISION APPROFONDIE
RAPPELS

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Q Question : nSDU et nPDU sont ils identiques?

Q Réponse : Non car il y a au moins des en-têtes de protocole rajoutés au nSDU pour en
faire un nPDU.
J Mais Non également car il y a possibilité de fragmentation :

J Une couche N recevant de son niveau supérieur un nSDU de données peut décider que la taille de
celui-ci est trop grande pour être admise par le protocole de niveau N. Dans ce cas, elle le découpe
en fragments de nSDU, chacun destiné à être habillé d'un entête de protocole de façon à en faire
un nPDU de données.

J Il est clair que les entêtes de protocole devront contenir une information permettant de détecter si
le nPDU de données reçu contient un bout (début, fin, milieu) ou la totalité d'un nSDU.

J Ainsi, un NPDU de 500 octets peut parfaitement passer sur un réseau TRANSPAC dont la taille de
paquets serait de 128 octets. Il y aura simplement fragmentation du NSDU de 500 octets en 3
paquets (NPDU) de 128 octets et 1 paquet (NPDU) de 116 octets. L'indication de fragmentation est
faite dans l'entête de paquet : c'est le bit M.

J Le nom ISO de cette opération est la segmentation. L'opération inverse s'appelle le réassemblage.

p16
PROTOCOLES TCP-IP VISION APPROFONDIE
RAPPELS

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
CONCATENATION

La couche N+1 fait de la concaténation : elle regroupe plusieurs


n+1 PDU pour former un seul n SDU

n+1 PDU n+1 PDU

N+1

n SDU n SAP

N
n SDU

n PDU

n - 1 SDU

F14-086

p17
PROTOCOLES TCP-IP VISION APPROFONDIE
RAPPELS

NTway.com Q Question : n+1PDU et nSDU sont ils identiques?


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Q Réponse : fréquemment oui dans les couches inférieures (NPDU et DLSDU, par exemple),
mais non théoriquement, car il existe une possibilité supplémentaire :

Q La concaténation
J L'idée résulte du constat selon lequel il peut arriver que plusieurs n+1PDU petits soient à
transférer entre les deux mêmes couches N+1, alors que la couche N est parfaitement capable de
s'échanger des données plus grandes.

J La couche N+1 est alors capable de grouper plusieurs n+1PDU déjà complètement formés dans un
même nSDU. la couche N dans ce cas n'est au courant de rien et remet à la couche N+1 distante le
nSDU complet. C'est cette dernière qui séparera les n+1 PDU les uns des autres.

J Le nom ISO de cette opération est la concaténation. L'opération inverse s'appelle la séparation.

p18
PROTOCOLES TCP-IP VISION APPROFONDIE
RAPPELS

NTway.com J Protocole
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Q Pour communiquer entre elles, les couches de mêmes niveaux ont besoin de définir des
conventions de dialogue normalisées : le protocole.

Q Un protocole de niveau 1 pourrait être, par exemple, l'avis V27ter du CCITT.

Q Un protocole de niveau 2 pourrait être, par exemple, HDLC LAPB.

Q Un protocole de niveau 3 pourrait être, par exemple, l'avis X25 Niv 3 du CCITT.

J Il existe deux grandes familles de protocoles :

J Les protocoles en mode connecté :

Q Un protocole en mode connecté nécessite avant tout échange de données, un échange


préalable, une mise en relation, pendant laquelle les deux couches homologues vont se
mettre d'accord sur la "manière de travailler".

Q Il ne s'agit pas nécessairement d'une négociation!

Q Par nature; un protocole en mode connecté est évolué, complexe, lent, et rend une grande
qualité de service.

p19
PROTOCOLES TCP-IP VISION APPROFONDIE
RAPPELS

NTway.com J Les protocoles en mode non connecté :


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Q Un protocole en mode non connecté ne nécessite pas de mise en relation préalable lors
d'un échange de données entre deux couches homologues. Ce type de protocole est
simple, basique : pas de mécanisme d'acquittement, de contrôle de flux, de numérotation.
La qualité de service est faible mais les échanges sont rapides.

J PDU
Q L'élément de données du protocole s'appelle un Protocol Data Unit (PDU).

J Les 2-PDU, ou DLPDU, sont les trames ;

J Les 3-PDU, ou NPDU, sont les paquets ;

J Les 4-PDU, ou TPDU, n'ont pas de noms particuliers ;

J Les 5-PDU, ou SPDU, n'ont pas de noms particuliers ;

J Les 6-PDU, ou PPDU, n'ont pas de noms particuliers ;

J Les 7-PDU, ou APDU, n'ont pas de noms particuliers ;

p20
PROTOCOLES TCP-IP VISION APPROFONDIE
RAPPELS

NTway.com F14-093
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
PROTOCOLE EN MODE CONNECTE
OU EN MODE NON CONNECTE

MODE CONNECTE
exemple de connexion

je souhaite échanger des octets,


ma taille maximum de buffer est 1024 octets,
et je numérote mes octets à partir de x.

d'accord, ma taille maximum de buffer est 1024,


je numérote mes octets à partir de y,
je m'attends à recevoir l'octet x+1.
COUCHE N COUCHE N
bien reçu, je m' attends à recevoir l'octet y+1

ECHANGE DE DONNEES

ACQUITTEMENT

MODE NON CONNECTE

échange DIRECT de données


pas d'acquittement
COUCHE N COUCHE N

p21
PROTOCOLES TCP-IP VISION APPROFONDIE
RAPPELS

NTway.com J Modélisation d'une passerelle.


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Q Il existe un fort besoin d'interconnexion entre réseaux. L'appareil dont on parle le plus
souvent est la passerelle. Une passerelle se définit par son plus haut niveau
d'interopérabilité.

J Niveau d'une passerelle :

Q Le niveau d'une passerelle est la plus haute couche impactée, ou vue, par la passerelle.
Ce concept est important car une passerelle est totalement transparente pour les couches
supérieures à son niveau, mais souvent non transparente, voire totalement opaque, pour
les autres couches.

Q Il existe un grand nombre de passerelles :

J des passerelles de niveau 0 (les connecteurs hermaphrodites IBM, par exemple) totalement
transparentes aux signaux électriques transportées (niveau 1);

J des passerelles de niveau 1 (les répéteurs ou les amplificateurs, par exemple), totalement
transparentes aux protocoles de liaison, mais parfaitement liées au signal employé;

J des passerelles de niveau 2 (les ponts Token Ring, par exemple), adaptées à un type de couche 2,
mais utilisables pour n'importe quelle couche 3;

p22
PROTOCOLES TCP-IP VISION APPROFONDIE
RAPPELS

NTway.com J des passerelles de niveau 3 (les routeurs IP, par exemple), adaptées à un nombre limité de
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma protocoles de niveau 3 (et donc opaques aux protocoles de niveau 3 inconnus), mais totalement
transparentes aux couches supérieures;

J des passerelles de niveaux 4, 5, 6 et 7, plus rares et très spécifiques.

J Le mode d'action d'une passerelle

Q Dans le cas d'une passerelle de niveau N, trois modes d'action sont souvent distingués,
bien que cette différentiation ne soit pas d'une très grande importance :

J on parle de commutateur lorsque les deux protocoles de niveau N sont identiques de part et
d'autre de la passerelle, mais sont corrélés (liens PDU - PDU);

J on parle de convertisseur lorsque les deux protocoles sont différents mais corrélés
(transformation PDU - PDU);

J on parle d'adosseur lorsque les deux protocoles, identiques ou différents, sont décorrélés et que la
correspondance se fait via les SDU.

p23
PROTOCOLES TCP-IP VISION APPROFONDIE
RAPPELS

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Modélisation d'une passerelle Vocabulaire

SEGMENT
N+1 N+1 Un bout de couche 0

N N N RESEAU LOCAL PHYSIQUE


1 1 Un ensemble de segments reliés
par des répéteurs

N-1 N-1 N-1 N-1


MAC MAC RESEAU LOCAL LOGIQUE
1 1 Un ensemble de réseaux locaux
phyqiques reliés par des ponts

EXEMPLE :
3
Routeur : (Passerelle de niveau 3)
Adaptés à un nombre limité de protocoles de niveau 3. 2 2
Totalement transparent aux couches supérieures.
1 1 IRLE
Pont ou Switch : (Passerelle de niveau 2) Un ensemble de réseaux locaux
Adaptés à un type de couche 2, mais utilisables logiques reliés par des routeurs
pour n'importe quelle couche 3.

Répéteur ou modem : (Passerelle de niveau 1)


Totalement transparents aux protocoles de liaison.

Prise : (Passerelle de niveau 0)

p24
PROTOCOLES TCP-IP VISION APPROFONDIE
RAPPELS

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

ENCAPSULATION

N N
Y22 Y22
Y21 Y21
N-1 Y20 Y20 N-1

F14-008

Q Modélisation de l'encapsulation

J C'est une opération qui consiste à mettre une couche N dans une couche Y22, c'est à dire dans
une couche qui n'a rien à voir. Un utilisateur de la couche N ne voit pas le tunnel, seule N voit le
tunnel.

p25
NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

-2-
HISTORIQUE ET EVOLUTION

p26
2 - HISTORIQUE ET EVOLUTION

NTway.com J INTERNET EN QUELQUES DATES :


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

A l'origine, les protocoles TCP-IP ont été développés par le département de la défense
Américaine pour leurs propres besoins.

De ce noyau est né le réseau Internet tel que nous le connaissons aujourd’hui.

Q 1969 : Naissance d'ARPANET (Advanced Research Project Agency NETwork)


J Démonstration privée de la faisabilité d'ARPANET, réseau à commutation de paquets composé de
4 nœuds.

Q 1973 : Démonstration d'ARPANET


J Démonstration publique d'ARPANET, réseau longue distance à commutation de paquets, 20
nœuds, 50 centraux.

J Création de l'INWG (Internet Working Group) afin de définir les apports de l'interconnexion de
réseaux indépendants.

p27
2 - HISTORIQUE ET EVOLUTION

NTway.com J INTERNET EN QUELQUES DATES :


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Q 1975 : UNIX et TCP-IP


J Définition de TCP par l'INWG et IFIP (International Fédération Information Processing).

J Diffusion d'UNIX dans les universités et les unités de recherche.

J Développement et implémentation de TCP dans les universités.

Q 1983 : TCP-IP remplace NCP


J ARPANET migre vers TCP

J ARPANET est divisé en deux réseaux MILNET et ARPANET.

J TCP-IP devient un standard militaire aux USA.

J Introduction par SUN de TCP-IP sur le marché commercial.

p28
2 - HISTORIQUE ET EVOLUTION

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
PROTOCOLES TCP-IP : LES ORGANISMES RESPONSABLES

DoD
Department Of Defense

structure officielle
IAB responsable des
Internet Architecture Board décisions concernant
l'architecture TCP-IP

IETF NIC NOC


Internet Engineering Network Network
Task Force Information Operation
Center Center

8 GROUPES DE TRAVAIL :
- Adresses IP, Gestion et
- APPLICATIONS : Telnet, E-Mail ... - RFC administration du
réseau Internet
- SERVICE AUX UTILISATEURS : mondial
FTP Anonymous, glossaires ...

- SECURITE : méthodes d'authentification,


sécurité de SNMP ...

- ADMINISTRATION : MIB ...

- TRANSPORT : DNS, DFS, Tansport Audio/Vidéo ...

- ROUTAGE : RIP, OSPF, IGP ...

- INTERNET : IP sur ATM, Appletalk, FDDI ...

- OPERATIONS : benchmark, statistiques ...

F05-093

p29
2 - HISTORIQUE ET EVOLUTION

NTway.com LA PILE DES PROTOCOLES TCP-IP


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Rlogin RPC
Rcmd BGP RIP
TELNET POP FTP SMTP HTTP DNS SNMP XDR PING ...
Rshell EGP/ PV IGP / DV
RCP NFS

SOCKET 5,6,7

OSPF IS-IS
TCP UDP ICMP IGP / LS IGP / LS 4

ARP RARP IP 3

SNAP X25

LLC T1 AAL
1, 2

Ethernet DIX ISO 8802.x PPP SLIP FR ATM HDLC

LAN WAN

p30
2 - HISTORIQUE ET EVOLUTION

NTway.com
Tél: 0-22-22-50-98 J Le rôle du modèle TCP/IP :
E-mail: ntway@iam.net.ma

Q Le rôle du modèle TCP/IP est de fédérer l'univers, c'est à dire de réaliser l'interopérabilité
horizontale entre les systèmes hétérogènes de l'univers. Cet objectif principal entraîne
deux sous-objectifs :

J La fédération de réseaux locaux (Ethernet, Token Ring ...).

J La configuration dynamique et autoadaptative des composants (ponts, routeurs), pour une


utilisation transparente pour l'utilisateur.

Q Le sigle TCP/IP englobe un ensemble de protocoles ou services.

J Couches 2 LAN :

Q Sous-couche MAC (Medium Access Control) :

J Ethernet DIX : Ethernet Digital Intel Xerox, standard de fait développé par Rank Xerox mais jamais
normalisé. La méthode d'accès au support est CSMA/CD (Carrier Sense Multiple Access With
Collision Detection). Il n'y a pas de couche LLC, donc pas de correction d'erreur et l'identification
de la couche supérieure se fera par la couche MAC.

J ISO 8802.x : les couches MAC normalisées par l'ISO.

J ISO 8802.3 : méthode d'accès au support CSMA/CD.

p31
2 - HISTORIQUE ET EVOLUTION

NTway.com J ISO 8802.4 : méthode d'accès au support Token Bus : bus à jeton.
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
J ISO 8802.5 : méthode d'accès au support Token Ring : anneau à jeton.

J ISO 8802.6 : normalisation de DQDB (Distributed Queued Dual Bus), réseau LAN, limite MAN, qu'on
peut appeler réseau de campus, fondé sur une technologie double bus, pouvant atteindre des
débits de 155 Mb/s.

J ISO 9514 : normalisation de FDDI (Fiber Distributed Data Interface), réseau de campus, caractérisé
par une technologie en double boucle (une en secours de l'autre), un support en fibre optique, des
débits à plus de 100 Mb/s, et une méthode d'accès à jeton qui garantit un temps d'accès
déterministe.

J Sous-couche LLC (Logical Link Control) :

J ISO 8802.2 T1: dite LLC1, couche LLC en mode non connecté, donc incapable de corriger les
erreurs. Son seul rôle sera donc d'identifier la couche supérieure, donc d'apporter les mécanismes
d'adressage de niveau LLC.

J ISO 8802.2 T2 : dite LLC2, couche LLC en mode connecté, donc offre toutes les fonctionnalités de
la couche LLC : correction d'erreurs et identification de la couche utilisatrice.

J Couches 2 WAN

Q HDLC : High level Data Link Control.


J Couche 2 en mode connecté donc qui corrige les erreurs, se trouve en général sous X25.

Q PPP : Point To Point Protocol.


J Protocole permettant de faire de l'IP sur des liens point à point.

p32
2 - HISTORIQUE ET EVOLUTION

NTway.com Q SLIP: Serial Line IP.


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
J Protocole permettant de faire de l'IP sur des liens point à point utilisés de façon asynchrone. Le
protocole SLIP a de plus en plus tendance à être remplacé par le protocole PPP.

J Couche 2 MAN

Q ATM : Asynchronous Transfer Mode.


J Technique de commutation de paquets rapide. Son principe de base consiste à découper les
informations à transmettre en petites cellules (5 octets d'en-tête et 48 de données) multiplexées sur
des supports communs. Cette technique permettant des débits de plus de 100 Mbit/s s'adapte
aisément à des débits d'usagers variables car la couche 2 est indépendante de la couche physique.
L'avenir d'ATM est très certainement les WAN très hauts débits.

Q Couches sous-réseau

J ISO 8208: Normalisation de X25. X25 est une couche 3 en mode connecté à part entière mais peut
être utilisée comme "couche 2" par IP, lorsque deux machines IP distantes doivent être connectées
par un réseau X25. Les NPDU IP sont alors encapsulés dans des paquets X25 ( tunnelling ).

J SNAP : SubNetwork Addressing Protocol, couche protocolaire au dessus de l'ISO dont le rôle sera
détaillé dans la suite de ce cours.

Q Couche inter-réseau

J IP : InternetProtocol. Protocole réseau en mode non connecté, souvent appelé protocole


réseau à datagramme.

p33
2 - HISTORIQUE ET EVOLUTION

NTway.com J Protocoles de niveau 3


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Q Le protocole ARP
J permet de découvrir l'adresse MAC d'une machine dont on connaît l'adresse IP.
Q C'est un protocole utilisant les broadcast de niveau MAC.

Q Le protocole repose sur deux datagrammes : ARP_REQ et ARP_RESP et nécessite une


propriété de diffusion (broadcast) sur le réseau local.

Q Le protocole RARP
J permet à une machine sans disque (diskless) d'obtenir une adresse IP à partir d'une adresse MAC.
Q Le mécanisme RARP utilise l'adresse MAC pour identifier de façon unique la machine
émettrice de la requête.

Q Un serveur primaire est affecté à chaque machine qui effectue une demande RARP, ainsi que
des serveurs secondaires en cas d'indisponibilité du serveur primaire.

J Protocole de rapport événementiel

Q ICMP:InternetControlMessageProtocol
J Protocole d'information entre nœuds utilisateurs du service Internet. ICMP est très lié à IP et permet
de faire des statistiques sur les NPDU perdus par IP par exemple.

p34
2 - HISTORIQUE ET EVOLUTION

NTway.com J Protocoles inter-routeurs


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Le rôle de ces protocoles est de permettre la propagation des informations entre les
routeurs et donc aux routeurs de s'auto-configurer automatiquement (deuxième objectif
des protocoles TCP/IP).

J Les protocoles distance vector

Les routeurs munis de ces protocoles s'échangent régulièrement leurs tables de routage
en entier. Celles-ci étant généralement grandes, les échanges se font peu souvent et
donc le temps de convergence est long. Le temps de convergence est l'intervalle de
temps entre un événement dans le réseau (panne de routeur, cassure de lien ...) et le
moment où toutes les tables de routage sont à jour.

Q GGP:GatewaytoGatewayProtocol
J Protocole de mise à jour des tables de routage au sein d'ARPANET. Il s'agit du prédécesseur de
RIP.

Q IGP:InternalGatewayProtocol
J Ensemble de protocoles de mise à jour des tables de routage au sein d'un système autonome
(exemples RIP, Hello, et des protocoles privés.)

Q RIP:RoutingInformationProtocol
J Il s'agit de l'IGP le plus utilisé aujourd'hui. Il s'appuie sur UDP. Sous Unix, il est présent au
travers du démon "routed".

p35
2 - HISTORIQUE ET EVOLUTION

NTway.com Q EGP:ExternalGatewayProtocol
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma J Protocole de mise à jour des tables de routage entre systèmes autonomes.
Il n'est plus guère utilisé aujourd'hui, on lui préfère BGP.

Q BGP:BorderGatewayProtocol
J Protocole de mise à jour des tables de routage entre systèmes autonomes, qui date des années 90,
et qui remplace progressivement EGP.

Remarque : un système autonome est une zone à l'intérieur de laquelle les routeurs
communiquent avec les mêmes unités de mesure.

J Les protocoles link state

Les routeurs munis de ces protocoles s'échangent régulièrement l'état des liens, et non
pas l'état des tables de routage entières, ce qui donne des temps de convergence
beaucoup plus courts. Il faut des routeurs très puissants pour ces types de protocoles car
les routeurs ont la topologie entière du réseau en mémoire et font des calculs d'itinéraires
de plus court chemin pour aller d'un point à un autre.

Q OSPF: Open Shortest Path First.


J C'est le plus célèbre des protocoles "link state". Le premier protocole "link state" a été développé
pour le réseau ARPANET en remplacement de GGP.

Q INTEGRATED IS TO IS :
J Il s'agit d'un protocole voisin d'OSPF, décrit dans la norme ISO 10589.

p36
2 - HISTORIQUE ET EVOLUTION

NTway.com J Couche transport


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Q TCP : Transmission Control Protocol
J Protocole responsable de l'adressage de niveau 4.
J Protocole de transport en mode connecté qui résout tous les problèmes résiduels du déplacement
de l'information :

Q Correction d'erreurs,
Q Réséquencement,
Q Allocation de ressources,
Q Contrôle de flux,
Q Adaptation du flux à la bande passante disponible.

Q UDP : User Datagram Protocol


J Protocole responsable de l'adressage de niveau 4.
J Protocole de transport en mode non connecté. Son objectif n'est pas la correction des problèmes
mais la rapidité.
J Attention : les protocoles applicatifs au-dessus devront prendre en compte les fonctionnalités
restreintes de UDP.
J Par exemple :

Q NFS ou TFTP, protocoles de niveau supérieurs transportés dans UDP vont corriger les
erreurs.
Q En revanche, SNMP assume la perte éventuelle d'un certain nombre de message.

p37
2 - HISTORIQUE ET EVOLUTION

NTway.com J API d'accès aux couches transport


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Q Socket:
J API du monde TCP/IP permettant d'accéder à TCP et à UDP. Elle est fortement liée au langage C.
Cette API est très répandue.

Q XTI:X/OPEN Transport Interface.


J API développée par AT&T sous le nom de TLI (Transport Layer Interface) et retenue par l'X/OPEN.
Sa principale caractéristique est de pouvoir s'appuyer indifféremment sur un transport OSI ou
TCP/UDP. Cette API est peu répandue. Elle a été conçue dans l'idée que des applications du monde
TCP/IP puissent migrer aisément vers les couches transport de l'OSI.

J Couches Session, Présentation et Application

Q TELNET : TELecommunication NETwork


J A la fois nom de l'application et du protocole de télé accès qui permet à un terminal connecté à un
système d'accéder à un autre système.

Q XDR : eXternal Data Representation


J Protocole de présentation d'origine SUN.

Q HTTP : Hyper Text Transfer Protocol


J Protocole utilisé pour transférer les requêtes d’accès à des documents HTML distants et les
réponses associées.

p38
2 - HISTORIQUE ET EVOLUTION
HISTORIQUE

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

API D'ACCES AUX COUCHES TRANSPORT

SOCKET ( d'origine BSD ) : très répandue

Socket

TCP UDP

IP

XTI (d'origine AT&T sous le nom de TLI) X/OPEN Transport


Interface : peu répandue

XTI
ISO 8602 ISO 8073
TCP UDP transport en mode transport en mode
non connecté connecté (5 classes)

IP ISO 8473 ou 8208

Conclusion

L' X/OPEN cherche à promouvoir les protocoles normalisés par l' ISO ?

F05-094

p39
2 - HISTORIQUE ET EVOLUTION

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

PRESENTATION DE L'APPLICATION TELNET

système1 système2

L S L S
O H O H
G E TCP-IP G E
I L I L
N L N L

telnet appelant telnet appelé

L'appelant se retrouve connecté au système 2 en mode caractère.


Inconvénients : - c'est le système 2 qui fait l'écho des caractères
- si on remplace TCP-IP par X25, les performances
diminuent.

Solution pour remplacer telnet sur X25 :

X29
programme d'accueil
cv du terminal
PAD
X3
X25
X28 TPAD HPAD

- X28 : décrit le dialogue entre un terminal asynchrone et un PAD.


- X29 : décrit le protocole entre un terminal X25 et un PAD dans le but
de transférer des données et de commander le PAD.
- X3 : avis du CCITT décrivant les fonctions du PAD.
F05-077

p40
2 - HISTORIQUE ET EVOLUTION

NTway.com Q FTP : File Transfer Protocol


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
J Protocole de transfert de fichiers.

Q SMTP : Simple Mail Transfer Protocol


J Protocole de messagerie du monde Internet.

Q POP : Post Office Protocol


J Protocole de messagerie permettant l'accès d'un poste client à un serveur de messagerie SMTP.

Q NVT:NetworkVirtualTerminal.
J Protocole de présentation de terminal virtuel.

Q Rcommand:Remote command
J (commande à distance) permettant d'effectuer sur une machine distante des actions précises. Les
Rcommand sont d'origine AT&T.

Q RLOGIN:
J permet la connexion à une machine distante.

Q RSHELL:
J permet de faire exécuter une commande spécifique au SHELL de la machine distante. Le SHELL est
l'interpréteur de commandes du système UNIX.

p41
2 - HISTORIQUE ET EVOLUTION

NTway.com Q RCP:Remote CoPy


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
J permet de copier un fichier vers ou en provenance d'une machine distante.

Remarque : RLOGIN et RCP ressemblent à TELNET et FTP. La différence majeure réside


dans les processus d'identification et d'authentification.

Q DNS : Domain Name System


J Service élaboré permettant de faire l'association entre un nom logique et une adresse Internet. DNS
est dans la pratique l’annuaire technique Internet/Intranet.

Q SNMP : Simple Network Management Protocol


J Protocole élaboré pour la gestion de réseaux TCP-IP par interrogation ou modification du contenue
d’une MIB (Management Information Base).

Q RPC : Remote Procedure Call


J Protocole qui permet à une machine de s'appuyer sur le système d'exploitation d'une machine
distante et de lui faire exécuter des appels systèmes. Aujourd’hui, le concept de RPC est utilisé
pour déporter de manière générale un grand nombre d'API.

Q NFS : Network File System


J Application de gestion de fichiers distribués de SUN présent sur la plupart des machines UNIX.

p42
2 - HISTORIQUE ET EVOLUTION

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

ILLUSTRATION DES RPC

A l'origine, dialogue interne dans un système.


Exemples :

programme utilisateur couche n programme

sous-programme,
fournisseur du service couche n-1 disque dur

API LOCALE NON EXPORTABLE

F05-091A

p43
2 - HISTORIQUE ET EVOLUTION

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

ILLUSTRATION DES RPC (suite)

Objectif des RPC : déporter le fournisseur du service.

client

i1
i2
annuaire ?

serveur

i1 Interprétation de la requête - problème éventuel de débit


- problème de localisation du fournisseur
i2 Redirection et déport de la de service
requête dans un protocole - problème de différence d'encodage
(syntaxe locale) entre le client et le serveur
- négociation ou non de l'encodage de
transfert (syntaxe de transfert)
Remarques
- Les protocoles de déport d'API constituent le "moteur système" du
Client-Serveur.
- L'intelligence se trouve chez le client.
- Attention aux débits!
Exemples
- RPC de SUN : standard du marché,
- NCS d'Apollo : retenu dans OSF-DCE sous le nom de RPC de l'OSF,
- ROSE : les RPC du modèle OSI.
Exemples d'applications Client-Serveur
- NFS sur SUN RPC,
- SQL et SQLNET vers un SGBD (Oracle, Informix ...)
F05-091B

p44
2 - HISTORIQUE ET EVOLUTION

NTway.com Q TFTP:
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
J Trivial FTP. Protocole de transfert de fichier s'appuyant sur UDP. Puisqu'il existe un risque de
perdre des données, TFTP gère les problèmes de perte de données.

Q SNMP:SimpleNetworkManagementProtocol
J Protocole permettant à des applications de gestion de réseau de s'échanger des informations
administratives. SNMP définit les protocoles inter applications, de même que la structure des bases
de données de gestion disponibles dans les différentes machines.

Q NCS:Network Computing System,


J fournit un service identique aux RPC, c'est à dire l'exécution d'appels système sur une machine
distante. NCS d'Appolo a été choisi par l'OSF.

Q RFS:Remote File Sharing.


J Système de gestion de fichiers distribués d'AT&T

p45
NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

-3-
LES COUCHES 1 ET 2 DANS
L'ARCHITECTURE TCP-IP

p46
3 - LES COUCHES 1 ET 2 DANS L'ARCHITECTURE TCP-IP
PRINCIPE GENERAL

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
L'architecture TCP-IP et le modèle OSI

Couche 7 APPLICATION
APPLICATION

Couches hautes
Couche 6 PRESENTATION APPLICATION REMARQUE :
PRESENTATION APPLICATION
Contrairement au modèle OSI,
c'est la même couche qui règle
les problèmes des couches
Couche 5 SESSION hautes.
SESSION

Couche 4 TRANSPORT TCP/ UDP


TRANSPORT TCP/ UDP

Couche 3 RESEAU IP
RESEAU IP

Couche 2 LIAISONS
LIAISONS
LIAISONS
LIAISONS
Couches basses

Couche 1 PHYSIQUE PHYSIQUE


PHYSIQUE PHYSIQUE

Couche 0 SUPPORT

p47
3 - LES COUCHES 1 ET 2 DANS L'ARCHITECTURE TCP-IP
PRINCIPE GENERAL

NTway.com J Principe général.


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Q L'architecture TCP-IP était initialement organisée essentiellement autour de couches 1 et 2


de type "réseau local" LAN.

Q Cette attitude a aujourd'hui évolué et il est possible de trouver des échanges protocolaires
IP au dessus de différents types de supports :

Q Toujours des réseaux locaux (LAN) :

J essentiellement ETHERNET

J mais aussi TOKEN RING

J FDDI

J …

Q Sur des liaisons spécialisées louées asynchrones en point à point.

p48
3 - LES COUCHES 1 ET 2 DANS L'ARCHITECTURE TCP-IP
PRINCIPE GENERAL

NTway.com Q Sur des réseaux X25. Dans ce cas, deux "écoles" se rencontreront :
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

J l'une considérant les liaisons à travers X25 comme un ensemble de liaisons spécialisées point à
point. Dans un tel cas, une machine X abonnée au réseau et accédant à 10 machines Y0 à Y9 est
vue comme disposant de 10 liaisons indépendantes.

J l'autre considérant au contraire le réseau X25 au complet comme un "réseau" auquel sont
connectés plusieurs abonnés. Dans un tel cas, une machine X abonnée au réseau et accédant à 10
machines Y0 à Y9 est vue comme disposant d'une seule liaison à un réseau unique auquel sont
attachées également Y0 à Y9.

Q Voir à la fin du chapitre IP : IP sur X25.

p49
3 - LES COUCHES 1 ET 2 DANS L'ARCHITECTURE TCP-IP
LE CAS PARTICULIER DES RESEAUX LOCAUX

NTway.com J LE CAS PARTICULIER DES RESEAUX LOCAUX :


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Q Le cas des réseaux de type CSMA/CD est aujourd'hui source de confusion. En effet deux
standards d'usage de ces réseaux coexistent aujourd'hui : la norme internationale ISO
8802 d'une part, le standard ETHERNET DIX d'autre part.

J L'ADRESSAGE DE NIVEAU MAC :

Q Les adresses sont sur 6 octets (48 bits) et doivent être uniques à l'intérieur d'un même
réseau local logique. Il existe deux façons de garantir cette unicité : soit de garantir
l'adresse unique dans l'univers, (Ethernet DIX et ISO GAA) soit de la garantir unique à
l'intérieur du réseau local logique par gestion manuelle rigoureuse (ISO LAA).

p50
3 - LES COUCHES 1 ET 2 DANS L'ARCHITECTURE TCP-IP
LE CAS PARTICULIER DES RESEAUX LOCAUX

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Les adresses MAC

UNE ADRESSE MAC DOIT ETRE UNIQUE A L'INTERIEUR D'UN


RESEAU LOCAL LOGIQUE

2 CULTURES

DIX ISO
GAA LAA
( Globally ( Locally
Administered Administered
Address) Address)

adresses garanties adresses gérées


uniques mondialement localement

adresses forcées dans adresses programmables


la carte coupleur par le logiciel

en principe non forçable adresses à maîtriser


par le logiciel gérer localement

p51
3 - LES COUCHES 1 ET 2 DANS L'ARCHITECTURE TCP-IP
LE CAS PARTICULIER DES RESEAUX LOCAUX

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Les adresses MAC (suite)

Ethernet DIX

1 bit 23 bits 24 bits

0 : unicast Vendor code


1 : multicast Code OUI (Organization Unique Identifier) adresse affectée par chaque
constructeur à chaque carte
FF FF FF FF FF FF : adresse de broadcast

ISO GAA
1 bit 1 bit 22 bits 24 bits
0

0 : unicast Vendor code


Code OUI (Organization Unique Identifier) adresse affectée par chaque
1 : multicast
constructeur à chaque carte
IBM 08 00 5A
BULL 08 00 38 Novell 00 00 1B
DEC 08 00 2B Unisys 08 00 06
SUN 08 00 20 Apple 08 00 07

ISO LAA
1 bit 1 bit 46 bits
1

0 : unicast
1 : multicast adresse à la disposition de l'utilisateur

p52
3 - LES COUCHES 1 ET 2 DANS L'ARCHITECTURE TCP-IP
LE CAS PARTICULIER DES RESEAUX LOCAUX
LE CAS PARTICULLIER DES RESEAUX LOCAUX
NTway.com J

Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Q Ethernet DIX :
J Ethernet Digital Intel Xerox, est un standard de fait, développé par Rank Xerox mais jamais
normalisé. La méthode d'accès au support est CSMA/CD (Carrier Sense Multiple Access With
Collision Detection)
J Ethernet Dix ne fait pas de correction d’erreur.
J L'identification de la couche supérieure se fait par le champ Frame type ou Ether Type.

Q La norme ISO. L’ISO a définie deux sous-couches dans la couche 2 : LLC et MAC
J La sous-couche MAC :

Q 8802.3 : Méthode d'accès au support CSMA/CD


Q 8802.5 : Méthode d'accès au support Token Ring
Q 8802.4 : Cas d'un accès au support Token Bus
Q 8802.6 : Définit la sous-couche 2 dans le cas d'un accès DQDB
Q 9314 : Définit la sous-couche 2 dans le cas d'un accès FDDI
Q L'identification de la couche supérieure se fait par la couche LLC 8802.2

J La sous-couche LLC 8802.2


Q L'identification de la couche supérieure se fait par les SAP id (Service Access Point id)
Q La couche LLC peut faire de la correction d'erreur (LLC Type 2). Cette fonction n'existe pas
en IP.

p53
3 - LES COUCHES 1 ET 2 DANS L'ARCHITECTURE TCP-IP
LE CAS PARTICULIER DES RESEAUX LOCAUX
LE CAS PARTICULLIER DES RESEAUX LOCAUX
NTway.com J

Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Q La norme ISO avec SNAP :


J L'ISO a du définir un autre service permettant de faire cohabiter les deux implémentations ci-après.
J Ce service est le SNAP qui permet véhiculer les Frame Type ou Ether Type dans une couche
normalisée par l’ISO.

p54
3 - LES COUCHES 1 ET 2 DANS L'ARCHITECTURE TCP-IP
LE CAS PARTICULIER DES RESEAUX LOCAUX

NTway.com IP sur LAN (Local Area Network)


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Implémentation Ethernet DIX (Digital Intel Xerox) :

3
IP ARP ...

0800 0806 Frame Type ou Ether Type

Ethernet
2 CSMA/CD

- Implémentation la plus couramment rencontrée aujourd'hui.

- Absence de couche LLC dans les trames Ethernet.

- Mécanisme d'identification de la couche supérieure par le champ Frame Type ou Ether Type

Structure d'une trame Ethernet DIX

Structure des MAC PDU ETHERNET (trames) ( chaque division représentant un octet )

préambule adresse MAC adresse MAC Frame " paquet " CRC
(8 octets) destinataire origine type IP - ARP - ... ( 4 octets )

F05-003

p55
3 - LES COUCHES 1 ET 2 DANS L'ARCHITECTURE TCP-IP
LE CAS PARTICULIER DES RESEAUX LOCAUX

NTway.com IP sur LAN (Local Area Network)


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Implémentation ISO :

3 IP SNA ... SAP : Service Access Point

06 04

2 ISO 8802.2 LLC

ISO 8802.X
MAC

L'implémentation ISO divise la couche 2 en deux sous couches :

- La sous-couche MAC : Medium Access Control :


* identifie la machine sur le réseau
*gère les problèmes d'accès au support physique
*détecte les erreurs de transmission

- La sous-couche LLC : Logical Link Control :


* corrige éventuellement les erreurs détectées par la sous-couche MAC
* identifie la couche supérieure

Structure d'une trame ISO 8802.3

Structure des MAC PDU ISO 8802.3 ( chaque division représentant un octet )

MAC
préambule adresse MAC adresse MAC MAC SDU CRC
SDU
(8 octets) destinataire origine ( = LLC PDU ) ( 4 octets )
size

F05-001

p56
3 - LES COUCHES 1 ET 2 DANS L'ARCHITECTURE TCP-IP
LE CAS PARTICULIER DES RESEAUX LOCAUX

NTway.com
Tél: 0-22-22-50-98 IP sur LAN (Local Area Network)
E-mail: ntway@iam.net.ma

Implémentation ISO/SNAP :

3 IP ARP ...

0800 0806 Frame Type ou Ether Type

AA SNAP : SubNetwork Access Point


SNAP
AA

2 ISO 8802.2 LLC

ISO 8802.X MAC

Le rôle du SNAP est de véhiculer les Frame Type ou Ether Type sur implémentation ISO

Structure d'une trame ISO avec SNAP


Structure proposée pour encapsuler les paquets IP/ARP/autres dans une forme ISO 8802 :
( chaque division représentant un octet )
MACPDU :

MAC
préambule adresse MAC adresse MAC MAC SDU CRC
SDU
(8 octets) destinataire origine ( = LLC PDU ) ( 4 octets )
size

LLCPDU :

DSAP SSAP SNAP Prot Id Frame Paquet


Ctrl
'AA' 'AA' '000000' type ETHERNET

F05-005

p57
3 - LES COUCHES 1 ET 2 DANS L'ARCHITECTURE TCP-IP
LE CAS PARTICULIER DES RESEAUX LOCAUX

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

J LA METHODE D'ACCES CSMA/CD

Q La confusion entre ISO 8802.3 et Ethernet DIX vient souvent du fait que ces deux
protocoles utilisent la même méthode d'accès au support, la méthode CSMA/CD.

Q Nous allons voir le fonctionnement de cette méthode.

p58
3 - LES COUCHES 1 ET 2 DANS L'ARCHITECTURE TCP-IP
LE CAS PARTICULIER DES RESEAUX LOCAUX

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
LA METHODE CSMA CD

2500 m
A ( max ) B

temps temps

Question
Qui détecte la collision ? la machine A, la machine B ou les deux?

F05-080A

p59
3 - LES COUCHES 1 ET 2 DANS L'ARCHITECTURE TCP-IP
LE CAS PARTICULIER DES RESEAUX LOCAUX

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
LA METHODE CSMA CD (suite)

2500 m
A ( max ) B

temps temps

Réponse

Personne!

F05-080B

p60
3 - LES COUCHES 1 ET 2 DANS L'ARCHITECTURE TCP-IP
LE CAS PARTICULIER DES RESEAUX LOCAUX

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
LA METHODE CSMA CD (suite)

2500 m
A ( max ) B

temps temps

Question

Qu'aurait-il fallu pour que A détecte la collision ?

F05-080C

p61
3 - LES COUCHES 1 ET 2 DANS L'ARCHITECTURE TCP-IP
LE CAS PARTICULIER DES RESEAUX LOCAUX

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma LA METHODE CSMA CD (suite)

2500 m
A ( max ) B

te = 2tp + ε

te : temps
d'émission

tp : temps de
propagation.

temps temps

Réponse
Qu'elle continue à surveiller le medium, donc à émettre.
Il est donc nécessaire d'émettre une trame de taille minimum :
46 octets pour le MAC SDU et 64 octets pour le MAC PDU.

F05-080D

p62
3 - LES COUCHES 1 ET 2 DANS L'ARCHITECTURE TCP-IP
LE CAS PARTICULIER DES RESEAUX LOCAUX

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
LA METHODE CSMA CD (suite)

A C B

temps temps

Question
Comment une machine qui n'a rien émis détecte une collision ?

F05-080E

p63
3 - LES COUCHES 1 ET 2 DANS L'ARCHITECTURE TCP-IP
LE CAS PARTICULIER DES RESEAUX LOCAUX

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

p64
3 - LES COUCHES 1 ET 2 DANS L'ARCHITECTURE TCP-IP
LE CAS PARTICULIER DES RESEAUX LOCAUX

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

LA GESTION DU PADDING SELON ETHERNET DIX


DANS LE CAS DE NPDU DE LONGUEUR FIXE

3 3
lg fixe lg fixe

LLC LLC

MAC MAC

Y X FT CRC Y X FT CRC

1 1

@MAC x @MAC y

Remarque
La couche Ethernet remet le padding à la couche supérieure.
La couche supérieure véhicule des PDU de longueur fixe.
La couche n+1 enlève le padding de niveau n.

F05-063

p68
3 - LES COUCHES 1 ET 2 DANS L'ARCHITECTURE TCP-IP
LE CAS PARTICULIER DES RESEAUX LOCAUX

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
LA GESTION DU PADDING SELON ISO 8802.3
POUR DES NPDU DE LONGUEUR FIXE OU VARIABLE

3 3

8802.2 8802.2
LLC

8802.3 8802.3
Y X LG CRC MAC Y X LG CRC

1 1

@MAC x @MAC y

Remarque

La couche 8802.3 ne remet pas le padding à la couche supérieure.


La couche n enlève le padding de niveau n.

F05-065

p69
3 - LES COUCHES 1 ET 2 DANS L'ARCHITECTURE TCP-IP
LE CAS PARTICULIER DES RESEAUX LOCAUX

NTway.com J LES COUCHES LLC DE L'ISO


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Q L'adressage :
J Le LLSAP id est codé sur un octet et permet d'identifier la couche supérieure à la couche LLC.

Q La structure du LLCPDU :
J Les MACSDU sont identiques aux LLCPDU (puisque la norme 8802.2 ne prévoit pas de
concaténation) et leur taille maximale autorisée est de 1500 octets.

J Les champs DLSAP (Destination Link Service Access Point) et SLSAP (Source Link Service Access
Point) permettent de multiplexer différents types d'échange au dessus des mêmes MAC_adresses.

Q La correction des erreurs par la couche LLC2 :


J Tout ce que remet la couche MAC à la couche LLC2 est correct mais il peut y avoir des oublis, en
cas de CRC incorrect par exemple. La couche LLC2 va donc corriger les erreurs par répétition.
Avant chaque envoi de LLCPDU, la couche LLC2 le garde en mémoire, arme un timer T1 et attend
un acquittement de la part de la couche LLC2 homologue. Si l'acquittement est reçu avant
l'expiration de T1, cela signifie que la couche LLC2 d'en face a bien reçu le LLCPDU et donc le
buffer peut être libéré. Par contre, si T1 expire, la couche LLC2 renvoie le LLCPDU qu'elle avait
gardé en mémoire.

J Vu de la couche LLC2, le temps de propagation est grand donc la couche LLC2 anticipe l'envoi des
données pour réduire l'impact du temps de propagation. La numérotation des données va de 0 à
127.

p70
3 - LES COUCHES 1 ET 2 DANS L'ARCHITECTURE TCP-IP
LE CAS PARTICULIER DES RESEAUX LOCAUX

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

LA GESTION DU PADDING SELON ETHERNET DIX


DANS LE CAS DE NPDU DE LONGUEUR FIXE

3 3
lg fixe lg fixe

LLC LLC

MAC MAC

Y X FT CRC Y X FT CRC

1 1

@MAC x @MAC y

Remarque
La couche Ethernet remet le padding à la couche supérieure.
La couche supérieure véhicule des PDU de longueur fixe.
La couche n+1 enlève le padding de niveau n.

F05-063

p68
3 - LES COUCHES 1 ET 2 DANS L'ARCHITECTURE TCP-IP
LE CAS PARTICULIER DES RESEAUX LOCAUX

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
LA GESTION DU PADDING SELON ISO 8802.3
POUR DES NPDU DE LONGUEUR FIXE OU VARIABLE

3 3

8802.2 8802.2
LLC

8802.3 8802.3
Y X LG CRC MAC Y X LG CRC

1 1

@MAC x @MAC y

Remarque

La couche 8802.3 ne remet pas le padding à la couche supérieure.


La couche n enlève le padding de niveau n.

F05-065

p69
3 - LES COUCHES 1 ET 2 DANS L'ARCHITECTURE TCP-IP
LE CAS PARTICULIER DES RESEAUX LOCAUX

NTway.com J LES COUCHES LLC DE L'ISO


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Q L'adressage :
J Le LLSAP id est codé sur un octet et permet d'identifier la couche supérieure à la couche LLC.

Q La structure du LLCPDU :
J Les MACSDU sont identiques aux LLCPDU (puisque la norme 8802.2 ne prévoit pas de
concaténation) et leur taille maximale autorisée est de 1500 octets.

J Les champs DLSAP (Destination Link Service Access Point) et SLSAP (Source Link Service Access
Point) permettent de multiplexer différents types d'échange au dessus des mêmes MAC_adresses.

Q La correction des erreurs par la couche LLC2 :


J Tout ce que remet la couche MAC à la couche LLC2 est correct mais il peut y avoir des oublis, en
cas de CRC incorrect par exemple. La couche LLC2 va donc corriger les erreurs par répétition.
Avant chaque envoi de LLCPDU, la couche LLC2 le garde en mémoire, arme un timer T1 et attend
un acquittement de la part de la couche LLC2 homologue. Si l'acquittement est reçu avant
l'expiration de T1, cela signifie que la couche LLC2 d'en face a bien reçu le LLCPDU et donc le
buffer peut être libéré. Par contre, si T1 expire, la couche LLC2 renvoie le LLCPDU qu'elle avait
gardé en mémoire.

J Vu de la couche LLC2, le temps de propagation est grand donc la couche LLC2 anticipe l'envoi des
données pour réduire l'impact du temps de propagation. La numérotation des données va de 0 à
127.

p70
3 - LES COUCHES 1 ET 2 DANS L'ARCHITECTURE TCP-IP
LE CAS PARTICULIER DES RESEAUX LOCAUX

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma STRUCTURE DU LLSAP id

LLSAP id destination :

Exemples :
0 : LLSAP unicast
1 : LLSAP multicast FE : OSI 8473
AA : SNAP
0 : LLSAP LAA 06 : IP
1 : LLSAP GAA 20 : OSI DSA ( Bull )
30 : TLD DSA ( Bull )
04 : PC d' IBM
F0 : Netbios
LLSAP id origine ( pour LLC2 ) :

0 : Primaire : Commande
1 : Secondaire : Réponse

0 : LLSAP LAA
1 : LLSAP GAA

F05-071

Structure des LLCPDU 8802.2 ( chaque division représentant un octet )

DLSAP SLSAP Ctrl


LLCSDU
1 octet 1 octet 1 ou 2 octets

F05-002

p71
3 - LES COUCHES 1 ET 2 DANS L'ARCHITECTURE TCP-IP
LE CAS PARTICULIER DES RESEAUX LOCAUX

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

DES EXEMPLES D'UTILISATEURS DE LA COUCHE


ISO 8802.2.

OSI 8473 OSI TLD SNA


option full DSA PC IP
ou null (Bull) (Bull) (IBM)

SNAP
FE 20 30 04 06 AA
LLSAP id

8802.2

MAC 8802.x

F05-074

p72
3 - LES COUCHES 1 ET 2 DANS L'ARCHITECTURE TCP-IP
LE CAS PARTICULIER DES RESEAUX LOCAUX

NTway.com J LA COHABITATION ETHERNET DIX ET ISO 8802.3.


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Q Sur le même câble.
J Cela ne pose pas de problèmes car le protocole de niveau 1 est identique (la détection de collisions
est faite de la même façon) et les adresses MAC identifient un point d'accès unique à l'intérieur d'un
réseau local logique. Le seul problème se situe au niveau des broadcast.

Q Sur le même driver.


J Un driver est un logiciel qui gère la carte réseau.
J Soit un driver multiprotocole qui gère à la fois Ethernet DIX et ISO 8802.3.

J Question : est-ce que A peut communiquer avec E ?, et C avec E ?.

J A priori non car la machine E ne peut faire la différence entre le champ longueur et le champ Frame
Type.

J L'ISO a alors consulté l'organisme responsable des Frame Type Ethernet DIX. Le plus petit est 0600
(XNS), soit 15536 en décimal. Donc en ISO 8802.3 il est impossible d'avoir un champ longueur
supérieur à 15536 octets. La taille maximum du LLCPDU = MACSDU a été fixée arbitrairement à
1500 octets. E peut facilement faire la différence entre le champ Frame Type et le champ longueur.

J Si ce champ est supérieur à 1500, alors c'est un Frame Type : c'est pour Ethernet DIX.

J Si ce champ est inférieur à 1500, alors c'est un champ longueur : c'est pour ISO 8802.3.

p73
3 - LES COUCHES 1 ET 2 DANS L'ARCHITECTURE TCP-IP
LE CAS PARTICULIER DES RESEAUX LOCAUX

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

LA COHABITATION ETHERNET DIX ET ISO 8802.3

Sur le même câble

A B C D
Eth DIX Eth DIX ISO ISO
8802.3 8802.3

adresse MAC x y z t
coexistence possible sur le même câble car même méthode d'accès au support
A et B peuvent communiquer (mêmes protocoles de niveau 2)
C et D peuvent communiquer (mêmes protocoles de niveau 2)
A et C ne peuvent communiquer (protocoles de niveau 2 différents)

Sur le même driver


E
A B C D Eth DIX
Eth DIX Eth DIX ISO ISO ISO
8802.3 8802.3 8802.3

adresse MAC x y z t w

communication possible entre A,B et E d'une part , et C,D et E d'autre part,


grâce à une "astuce" :
- le plus petit Frame Type 0600 (XNS) = 1536
- la longueur maximale d'un MACSDU ISO 8802.3 est de 1500 octets.

F05-115

p74
3 - LES COUCHES 1 ET 2 DANS L'ARCHITECTURE TCP-IP
LE CAS PARTICULIER DES RESEAUX LOCAUX

NTway.com J LE ROLE DU SNAP.


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Q L'empilement normalisé par l'ISO : IP sur ISO 8802.2 de type 1 avec LLSAPid 06. Le
problème est que seul IP a été normalisé. Il manque les autres protocoles nécessaires à IP
pour fonctionner (ARP, RARP ...) donc une proposition a été faite pour régler ce problème :
véhiculer les anciens empilements avec les Frame Type sur une couche normalisée par
l'ISO, le SNAP.

Q Le rôle du SNAP est de véhiculer les Frame Type et donc de promouvoir les couches
basses de l'ISO

Structure proposée pour encapsuler les paquets IP/ARP/autres dans une forme ISO 8802 :
( chaque division représentant un octet )
MACPDU :

MAC
préambule adresse MAC adresse MAC MAC SDU CRC
SDU
(8 octets) destinataire origine ( = LLC PDU ) ( 4 octets )
size

LLCPDU :

DSAP SSAP SNAP Prot Id Frame Paquet


Ctrl
'AA' 'AA' '000000' type ETHERNET

F05-005

p75
3 - LES COUCHES 1 ET 2 DANS L'ARCHITECTURE TCP-IP
LE CAS PARTICULIER DES RESEAUX LOCAUX

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

LE ROLE DE LA COUCHE SNAP

ETHERNET DIX

IP RARP ARP XNS IPX


OSI OSI TLD SNA IP
8473 DSA (Bull) PC 0800 8035 0806 0600 8137
(IBM)
SNAP
FE 20 30 04 06 AA

8802.2

8802.X

TELECOMS ISO

F14-015

p76
3 - LES COUCHES 1 ET 2 DANS L'ARCHITECTURE TCP-IP
LE CAS PARTICULIER DES RESEAUX LOCAUX

NTway.com J CONCLUSION
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Q Il existe trois différents empilements de IP sur LAN schématisés sur les dessins ci-
dessous.

DIFFERENTS EMPILEMENTS POUR TCP-IP SUR LAN

Très fréquents

Origine Ethernet

Support aujourd'hui OSI 8802.2/ 8802.x

TCP UDP TCP UDP TCP UDP

IP ARP
IP ARP... IP 0800 0806
06 SNAP
AA
0800 0806 8802.2 LLC1 8802.2 LLC1
Ethernet 8802.x 8802.x

C1 C2 C3

Remarque
Le mode C2 est aujourd'hui obsolète et nécessite de
travailler en LAA au niveau MAC.
Les modes C1 et C3 se partagent le marché.
C1 >> C3
Mais l'avenir est à C3.
F05-069

p77
3 - LES COUCHES 1 ET 2 DANS L'ARCHITECTURE TCP-IP
LE CAS PARTICULIER DES WAN

NTway.com J LE CAS PARTICULIER DES WAN (Wide Area Network)


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma On peut distinguer deux familles de protocoles de réseaux WAN.
IP sur réseau longue distance - WAN - (Wide Area Network)

Les réseaux WAN utilisant des routeurs avec


les protocoles PPP, SLIP, HDLC et propriétaires

IP

Propriétaires
PPP SLIP HDLC ex. Cisco

Les réseaux WAN utilisant des équipements mettant en oeuvre


la commutation type X25, Frame Relay ou ATM

IP

Frame
X25 ATM
Relay

p78
3 - LES COUCHES 1 ET 2 DANS L'ARCHITECTURE TCP-IP
LE CAS PARTICULIER DES WAN
IP sur PPP : Point to Point Protocol
NTway.com J

Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Q C'est le protocole le plus utilisé par IP sur un lien WAN type RNIS, Ligne Spécialisée, RTC,
...

Q PPP est multiprotocolaire (c'est-à-dire qu'il peut véhiculer sur le même lien plusieurs
protocoles).

Q PPP offre des possibilités :


J de détection d'erreur sans correction
J d'identification/authentification (PAP/CHAP)
J de tests de lignes.

Q C'est, en général, le protocole utilisé lorsqu'on accède à Internet par un fournisseur


d'accès. On peut le considérer comme le remplaçant de SLIP.

Q PPP est un protocole de gestion de lien et non un protocole de commutation :


J PPP peut être utilisé sur un lien permanent Ligne Spécialisée ou sur un réseau à commutation de
circuit comme RTC.
J PPP peut être aussi utilisé sur des circuits virtuels Relais de trames ou ATM.

p79
3 - LES COUCHES 1 ET 2 DANS L'ARCHITECTURE TCP-IP
LE CAS PARTICULIER DES WAN

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Format d'une trame PPP, RFC 1171 et 1172

FCS Flag
2 octets 1octet

Fin de trame
en-tête PPP Datagramme IP
PPP

PPP : Point to Point Protocol

4 fonctionnalités principales :

- une méthode pour encapsuler les datagrammes


sur des liens série asynchrones.
identifie le protocole
Flag adresse control
transporté
1 octet 1 octet 1 octet 2 octets - un protcole LCP (Link Control Protocol) pour
établir, configurer et tester la liaison.

- une famille de protocoles NCP (Network Control


Protocol) qui établit et configure les différentes couches
trois pouvant être utilisées simultanément.

- permet l'identification/authentification.

p80
3 - LES COUCHES 1 ET 2 DANS L'ARCHITECTURE TCP-IP
LE CAS PARTICULIER DES WAN

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma Signification et valeur des champs d'une trame PPP

Flag : 1 octet.
Valeur binaire 01111110
Address : 1 octet.
Valeur toujours 111111111 -toutes les stations -
Les versions futures prévoient l'adressage individuel de
FCS Flag station
Control : 1 octet
Valeur 00000011 (HDLC commande avec le bit P/F
positionné à 0)
Protocol : 2 octets, identifiant le protocole encapsulé
dans le champ information de la trame PPP.
Fin de
en-tête PPP Datagramme IP trame - Info field Protocol
PPP - 0021 IP
- 0023 OSI
- 0027 DECnet phase IV
- 0029 Apple Talk
- 002B Novell IPX
- 002D Van Jacobson compressed TCP-IP
Flag address control - 8021 PPP IP Control Protocol
Protocol
- 8029 PPP Apple Talk Control Protocol
- 802b PPP IPX Control Protocol
- C021 PPP Link Control Protocol
- C023 PPP Password Authentication
Protocol
- C223 PPP Challenge Handshake
Authentication Protocol
FCS : 2 octets, valeur de checksum calculée pour le
contrôle d'erreur (algorithme décrit dans ISO 3309)

p81
3 - LES COUCHES 1 ET 2 DANS L'ARCHITECTURE TCP-IP
LE CAS PARTICULIER DES WAN

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma PPP - LCP (Link Control Protocol)

LCP

I
en-tête PPP Code Longueur Options fin de trame PPP
D

PPP est un protocole de couche 2 orienté connection :

- une demande de connection, des échanges en cours de


connection et une demande de fin de connection est nécessaire
au fonctionnement de PPP.

LCP
- Le PPP Link Control Protocol est le protocole utilisé pour
établir, configurer, maintenir et terminer une connexion point à
Flag FF 03 C021 point.
- Les paquets LCP sont encapsulés dans une trame PPP
avec le champ "protocol" a une valeur de OX'C021'.
- Le protocole LCP contient un champ "code" informant sur
la nature de l'information avec un format général :

Les différentes valeurs du champ "Code"


-1 configure-request
-2 configure-ack
-3 configure-nack
-4 configure-reject
-5 terminate-request
-6 terminate-ack
-7 code-reject
-8 protocol-reject
-9 echo-request
- 10 echo-reply
- 11 discard-request

p82
3 - LES COUCHES 1 ET 2 DANS L'ARCHITECTURE TCP-IP
LE CAS PARTICULIER DES WAN

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

LE PROTOCOLE LPC D'ETABLISSEMENT DE LIEN


PPP

Modem Modem

Poste de travail Poste de travail


async async

PPP LCP PPP

I
Flag FF 03 C021 1 Longueur Options CRC Flag
D

Description de la trame PPP d'établissement d'un lien :

En-tête PPP

LCP :

Champ "code" = 1 (configure-request)

Champ "Identifier" = valeur de champ qui peut changer à chaque transmission. En réception, la valeur de ce
champ peut être copier dans le champ ID du paquet de réponse.

Champ "Longueur" = longueur de la trame LCP

Champ "Options" = champ variable en longueur. Il contient une série de 0 ou bien des valeurs permettant à
celui qui demande à établir le lien de négocier certaines options.

p83
3 - LES COUCHES 1 ET 2 DANS L'ARCHITECTURE TCP-IP
LE CAS PARTICULIER DES WAN

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
LE CHAMP "OPTIONS" DE CONFIGURATION LPC

TYPE Longueur Data ...

TYPE : 1 octet.
Indique le type d'option de configuration. Les valeurs les
plus courantes que peut prendre ce champ sont décrites
dans le RFC 11 "Assigned Numbers" :
-1 Maximum-Receive-Unit
-2 Async-Control-Character-Map
-3 Authentication-Protocol
-4 Quality-Protocol
-5 Magic-Number
-6 RESERVED
-7 Protocol-Field-Compression
-8 Address-and-Control-Field-Compression

Longueur : 1 octet.
Indique la longueur de cette option de configuration ;
champ TYPE, Longueur et Data inclu. Si une trame
"Configure-Request" contenant une demande de
négociation d'option est reçue avec un champ longueur
invalide, une trame "Configure-Nack" peut alors être
transmise.

Data : 0 ou plus octet.


Indique la valeur ou d'autres informations pour cette option
de configuration. Le format et la longueur du champ Data
sont déterminés par les champ TYPE et Longueur.

p84
3 - LES COUCHES 1 ET 2 DANS L'ARCHITECTURE TCP-IP
LE CAS PARTICULIER DES WAN
IP sur SLIP : Serial Line IP (RFC 1055)
NTway.com J

Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Q Il n'existe pas de standard pour encapsuler IP sur des lignes séries. SLIP, Serial Line IP,
est généralement un standard de fait, utilisé couramment sur des liens point à point qui
gèrent TCP/IP. SLIP n'est pas un standard Internet.

J Historique :

Q SLIP trouve ses origines dans l'implémentation 3COM UNET TCP/IP, datant des années 80.
Il s'agit simplement d'un protocole d'encapsulation de paquets : SLIP définit une séquence
de caractères qui encadrent les datagrammes IP sur une ligne série, rien de plus. Il ne
fournit pas d'adressage, pas d'identification du type de datagramme, pas de
détection/correction d'erreur, ni de mécanismes de compression. Parce que ce protocole
fait si peu de choses, il est réellement très facile à implémenter.

Q Autour des années 1984, Rick Adams a implémenté SLIP sur la version 4.2 d'UNIX Berkeley
et sur les stations SUN, et le délivra au monde entier. Très rapidement, cela est devenu un
moyen facile de connecter les hosts TCP/IP et les routeurs à l'aide de liens séries.

Q SLIP est généralement utilisé sur des lignes séries dédiées. Il est utile pour permettre le
mixage de hosts et de routeurs destinés à communiquer ensemble. (host-host, host-
routeur, routeur-routeur, sont des configurations banales des réseaux SLIP).

p85
3 - LES COUCHES 1 ET 2 DANS L'ARCHITECTURE TCP-IP
LE CAS PARTICULIER DES WAN
Le protocole :
NTway.com J

Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Q Le protocole SLIP définit deux caractères : END et ESC. END est 192, et ESC est 219 pour
ne pas confondre avec les caractères ASCII.

Q Pour envoyer un paquet, un host SLIP envoie simplement la donnée dans le paquet.

J Si l'octet de la donnée est le même code que END, une séquence de deux octets ESC est envoyéeà
la place.

J Si l'octet de la donnée est le même code que ESC, une séquence de deux octets ESC est envoyée à
la place.

Q Quand le dernier octet du datagramme a été envoyé, un caractère FIN est transmis

Q Parce qu'il n'y a pas de spécification "standard" de SLIP, il n'y a pas vraiment une taille
maximum de paquet pour SLIP. Le mieux est d'accepter la taille maximum utilisée par les
drivers d'UNIX BSD : 1006 octets, incluant les en-têtes IP et de transport, (sans inclure les
caractères d'encapsulation). C'est pourquoi n'importe quelle nouvelle implémentation de
SLIP doit être préparée à accepter des paquets de 1006 octets et ne doit pas envoyer plus
de 1006 octets dans un datagramme.

p86
3 - LES COUCHES 1 ET 2 DANS L'ARCHITECTURE TCP-IP
LE CAS PARTICULIER DES WAN
Défauts :
NTway.com J

Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Q Il existe certains traits du protocole qui ne sont pas implémentés par SLIP et qui pourraient
être nécesaires aux protocoles utilisateurs. dans tous les cas,SLIP est juste un protocole
très simple conçu il y a longtemps quand ces problèmes n'étaient pas vraiment critiques.
Les défauts de SLIP sont :

1. l'adressage.

J Dans un lien SLIP, les deux machines communicantes ont besoin de connaître leurs adresses IP
respectives pour d'éventuelles fonctions de routage.

2. le type d'identification.

J Il n'existe pas de champ "type" dans le protocole SLIP. Donc un seul protocole peut tourner au
dessus d'une connexion SLIP.

J SLIP EST MONOPROTOCOLE!

3. La détection/correction d'erreurs.

J En général; la vitesse de transmisison de la ligne est faible (2400 Bauds par exemple), donc la
retransmission coûte cher. Il serait appréciable que SLIP fournisse un simple mécanisme de
détection d'erreurs pour la couche supérieure.

p87
3 - LES COUCHES 1 ET 2 DANS L'ARCHITECTURE TCP-IP
LE CAS PARTICULIER DES WAN

NTway.com 4. La compression.
Tél: 0-22-22-50-98 J A cause de la relative lenteur des lignes, la compression des données serait une amélioration
E-mail: ntway@iam.net.ma
considérable du protocole.

J Des groupes de travail ont été constitués par l'IETF pour concevoir et implémenter un protocole
SLIP palliant tous ces défauts.

J IP sur HDLC-LAPB :
Q Il s'agit d'une implémentation monoprotocolaire.

Q Dans ce cas on a une couche 2 qui fait de la correction d'erreur, en mode connecté
(rétention, gestion de timer de surveillance et gestion de ack) donc c'est un protocole très
lourd pour transporter IP.

Q On l'utilise pour fiabiliser une Liaison Spécialisée défaillante sur un réseau IP.

J IP sur Protocole Propriétaire


Q Exemple "HDLC Cisco".

Q Offre de nombreux avantages techniques, comme :


J La détection d'erreur,
J La compression de données.

Q Obligation d'avoir le même fournisseur d'un point à l'autre.


p88
3 - LES COUCHES 1 ET 2 DANS L'ARCHITECTURE TCP-IP
LE CAS PARTICULIER DES WAN

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma Evolution des Architectures Technique Telecom
Couche 4 : légère voire vide, parfois lourde
pour offrir notamment des capacités de
couche 4 CCV CCV CCV couche 4
multiplexage supplémentaire

couche 3 couche 3 couche 3 couche 3 Couche 3 : routage, contrôle de flux,


couche 3
garantie de séquencement (mode chemin CV)
garantie de signalisation de problème
couche 2 couche 2 couche 2 couche 2 couche 2 (ex. : X25 paquet de libération)

Couche 2 : détectant, corrigeant les erreurs


couche 1 couche 1 couche 1 couche 1 couche 1 et attenuant les défauts du niveau 1
(ex. : mode connecté LAPB)

Couche 4 :lourde réglant tout les problèmes


couche 4 Routeur Routeur Routeur couche 4 non résolus. (TCP)

Couche 3 :routage, pas de contrôle de flux,


couche 3 couche 3 couche 3 couche 3 couche 3
pas de garantie de séquencement , pas de
garantie de signalisation de problème.
couche 2 couche 2 couche 2 couche 2 couche 2 Performance du routage est le maître mot (IP)

Couche 2 :détectant, mais ne corrigeant plus


couche 1 couche 1 couche 1 couche 1 couche 1 les erreurs (PPP, SLIP, HDLC-Cisco...)

REMARQUE
Puisque le chemin a disparu, les dispositifs de gestion de priorité
ne peuvent être mis que localement dans les routeurs.

p89
3 - LES COUCHES 1 ET 2 DANS L'ARCHITECTURE TCP-IP
LE CAS PARTICULIER DES WAN

NTway.com J LE RELAIS DE TRAMES (Frame Relay) :


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Q Le relais de trames est né en 1988, s'est imposé à partir de 1992 et a eu du mal à


convaincre l'Europe.

Q Le relais de trames fonctionne en mode connecté.

Q Un circuit virtuel doit être établi et actif avant de pouvoir envoyer des données.

Q Le but de ce CV (=contrat) est d'avoir une réservation de ressources cohérentes par tous
les équipements traversés (on parle de Qualité de Service ou de QoS).

Q L'objectif de ce CV, outre la QoS (Quality of Service) est d'améliorer les performances :

J abandon de la correction d'erreur de proche en proche


J abandon de la commutation de niveau 3 au profit de la commutation de niveau 2 (plus de contrôle
de flux de proche en proche)

Q Diminuer les temps de traversée notamment par rapport à X25

Q L'état du marché est important car il a séduit par sa maturité et sa simplicité mais
malheureusement il est essentiellement CV permanent.

p90
3 - LES COUCHES 1 ET 2 DANS L'ARCHITECTURE TCP-IP
LE CAS PARTICULIER DES WAN

NTway.com J LE RELAIS DE TRAMES (Frame Relay) :


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Q Deux visions architecturales possibles

Q Le client loue un/des CVP et peut envoyer des trames sur ce/ces CVP.

Q Chaque trame transporte un numéro indiquant le CV (n° de DLCI Data Link Circuit
Identifier) à utiliser.

Q Il existe un protocole ARP aménagé pour le relais de trames. Cet ARP permet de découvrir
quel Circuit Virtuel utilisé correspond à telle adresse IP.

Q INV_ARP permet la découverte de l'adresse IP au bout du Circuit Virtuel.

Q L'empilement est décrit dans le RFC 1490.

p91
3 - LES COUCHES 1 ET 2 DANS L'ARCHITECTURE TCP-IP
LE CAS PARTICULIER DES WAN

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Deux visions architecturales du réseau Relais de Trames par IP
Vision LAN Vision Ligne Spécialisée
Le backbone est vu comme un réseau local.

Soit table statique faisant la correspondance entre le n° de DLCI et @IP Chaque circuit virtuel commuté ou permanent est considéré comme une Ligne Spécialisée.

Soit INV_ARP multidiffusé sur tous les DLCI locaux Ce choix est consommateur d'adresse de réseau IP.
- Le routeur DLCI x demande : quel est l'adresse IP qu'il y a au bout ?
- Le routeur concerné répond : @IP 192.93.10.2 Table statique dans les équipements pour assurer la correspondance n°DLCI / @IP

@IP 192.93.10.4 @IP 192.93.10.5 CV vu


@IP 192.93.10.6
comme LS
@IP 192.93.11.0/24 @IP 192.93.14.0/24
DLCI x @IP 192.93.12.0/24 @IP 192.93.15.0/24
@IP 192.93.13.0/24 @IP 192.93.16.0/24
Un n° de DLCI
est local à la machine

BACKBONE
RELAIS DE TRAMES BACKBONE
RELAIS DE TRAMES

DLCI y

@IP 192.93.10.3 @IP 192.93.10.2


@IP 192.93.10.0/24 @IP 192.93.7.0/24
@IP 192.93.9.0/24 @IP 192.93.6.0/24
@IP 192.93.8.0/24 @IP 192.93.5.0/24

ATTENTION : comme dans le cas de IP sur un backbone X25


Il y a autant de circuit virtuel dans la vision de droite et de gauche.

p92
3 - LES COUCHES 1 ET 2 DANS L'ARCHITECTURE TCP-IP
LE CAS PARTICULIER DES WAN

NTway.com J ATM (Asynchronous Transfer Mode) :


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Q Objectif :

J Fournir une technologie devant écraser les temps de traversée (de l'ordre de 5 à 10 ms).
J Garantir des temps de traversée stables.
J Gestion extrêmement fine de la QoS.
J Utilisable sur n'importe quel support
J Atteindre des puissances de commutation très élevées.

Q L'ATM met en œuvre une commutation hardware de cellules fixes et petites (48 octets+5
octets d’en-tête).

Q La technologies ATM permet de véhiculer, sur un même réseau, des données d’origine
téléphonique, informatique ou audiovisuelle.

Q Pour ce faire, le réseau doit se renseigner auprès de l’usager sur le type de connexion
souhaité. Cela se traduit par une phase de négociation de la qualité de service.

p93
IP, ATM ET ADSL
NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma J Une offre passionnante : Assymetric Digital Subscriber Line
Q pour les accès opérateurs
Q pour les réseaux de campus
J L ’idée majeure consiste à réutiliser l ’infrastructure capillaire

TCP UDP TCP UDP

IP IP
AUTHENTIFICATION
AUTHENTIFICATION

PPOE PPOE 2

ETHERNET ETHERNET ETHERNET

AAL5 1
AAL5 AAL5
AAL5
800
800KK
ATM ATM ATM
ATM ATM ATM
ADSL ADSL SDH
ADSL SDH SDH

8M
8M DSLAM
DSLAM BAS
BAS
Digital
Digital
ADSL
ADSL Subscriber Broad
Broad
Subscriber Acces
PPOE
PPOE:: Line
Line Acces
Point Distance limitée Acces Server
Server
Pointto
toPoint
PointProtocole
ProtocoleOver
OverEthernet
Ethernet Acces
Multiplexor
Multiplexor

p94
3 - LES COUCHES 1 ET 2 DANS L'ARCHITECTURE TCP-IP
LE CAS PARTICULIER DES WAN

NTway.com J IP SUR ATM (Asynchronous Transfer Mode)


Tél: 0-22-22-50-98
Q L'implémentation de IP sur ATM offre trois visions architecturales possibles :
E-mail: ntway@iam.net.ma

J ATM vision Ligne Spécialisée.

Ou bien le Backbone ATM est vue comme un réseau local logique.


Dans ce cas deux architectures ont été définies :

J IETF : Classical IP : RFC 1577 et 2225


Q Vision d'un ensemble de commutateurs et de stations ATM en réseau local.

Q Utilisable uniquement en IP.

Q Tous les équipements font partis du même sous réseau.

Q L'adresse ATM joue le rôle de l'adresse MAC

Q On utilise un serveur ARP (ATM-SERVEUR) pour déterminer l'adresse ATM à partir de

l'adresse IP
Q Le Broadcast et le Multicast ne sont pas possibles.

J ATM forum : Lan Emulation : RFC 1483


Q Même objectif que Classical IP : vision d'un ensemble de commutateur et de stations ATM en

réseau local.
Q Lan Emulation est utilisable dans n'importe quel environnement Protocolaire, IP, IPX,

NetBeui, SNA, Apple Talk, OSI…


Q Les dispositifs de Broadcast et de Multicast de niveau MAC classiques sont disponibles.

p95
3 - LES COUCHES 1 ET 2 DANS L'ARCHITECTURE TCP-IP
LE CAS PARTICULIER DES WAN

NTway.com J LES RPV ou VPN (Virtual Private Network)


Tél: 0-22-22-50-98
Q IP V4 n'a pas été conçu pour garantir la sécurité des informations qu'il transporte.
E-mail: ntway@iam.net.ma

Q Pour assurer la sécurité l'offre des opérateurs est bâtie essentiellement sur les CV ATM
(pour des débits supérieurs à 2 Mbits/s) et Relais de Trames (pour des débits faibles).
Cette offre sous-tend un accès via le réseau privé de l'opérateur.

Q La mise en œuvre de VPN rend possible aujourd'hui l'utilisation du réseau Internet pour
des accès Intranet, Extranet et nomade grâce au standard IPsec (IP Security).

Q La mise en œuvre de IPSec peut permettre d'assurer :


J la confidentialité des données transportées
J l'intégrité des données transportées
J l'authentification de l'origine
J un contrôle d'accès
J une protection partielle contre le rejeu.

Q IPSec peut fonctionner suivant deux modes :


J le mode transport
J le mode tunnel

Q Ces services sont basés sur des mécanismes cryptographiques. Pour cela, IPsec fait appel
à un protocole de sécurité qui vient s'ajouter au protocole IP classique : ESP
(Encapsulating Security Payload).

p96
NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

-4-
ADRESSAGE IP

p97
4 - ADRESSAGE IP

NTway.com J PRINCIPE GENERAL :


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Q Dans le cadre de TCP/IP, c'est la couche de réseau IP (Internet Protocol) qui sera la couche
de réseau présente dans toutes les machines du réseau.

Q Bien que non nécessaire pour des dialogues internes au réseau local, elle sera utilisée
systématiquement à l'intérieur du réseau local ou pour en sortir.

Q Les adresses logiques de réseau mises en oeuvre par la couche IP sont des adresses 32 bits
définies en principe en accord avec les administrateurs du réseau ARPANET aux Etats Unis
(NIC : Network Information Center), de façon à ce qu'elles soient uniques et affectées par
définition à chaque accès physique sur un réseau.

Q Ces adresses ayant été imaginées pour travailler sur n'importe quel support physique, (pas
seulement un réseau local) sont à priori indépendantes des adresses physiques des cartes
contrôleurs du réseau local, elles aussi uniques, mais définies par d'autres organismes.

Q La translation de ces adresses logiques de réseau IP en adresses physiques sur un réseau


local, effectuée par la gateway de passage vers le réseau destinataire, mais aussi par
l'émetteur vers sa gateway de passage, est une opération automatique effectuée par un
algorithme dit ARP (Address Resolution Protocole).

p98
4 - ADRESSAGE IP

NTway.com Q Il nécessite pour fonctionner que le réseau physique sous-jacent ait une propriété de
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma diffusion (broadcasting).

Q D'autres possibilités d'affectation existent, notamment via la configuration de l'interface.

J LES CLASSES D'ADRESSAGE IP


Q L'adressage IP est corrélé géographiquement, donc l'adresse de la machine dépend de
l'endroit où elle se trouve et se compose de deux champs : le numéro de réseau et le numéro
de la machine sur ce réseau. Les adresses IP sont codées sur 32 bits et sont en principe
définies par le NIC aux Etats-Unis et par l'INRIA pour la France.

Q Il existe quatre grandes classes d'adresses IP définies par la répartition entre le nombre de
bits qui indiquent le numéro de réseau et les suivants qui donnent le numéro de la machine
dans ce réseau. La frontière entre le numéro de machine et le numéro de réseau est déduite
des quatre premiers bits d'adresse.

Q classe A : premier bit à 0


J Il y a 7 bits pour le numéro de réseau et 24 bits pour le numéro de machine sur ce réseau, ce qui fait
126 réseaux possibles (27 - 2 car tout à 0 et tout à 1 est interdit), et 16777214 machines (224) par
réseau.

p99
4 - ADRESSAGE IP

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Q classe B : 10 pour les deux premiers bits
J Il y a 14 bits pour le numéro de réseau, soit 16382 réseaux possibles (214 - 2) et 16 bits pour le numéro
de machine, soit 65534 machines par réseau.

Q classe C : 110 pour les trois premiers bits


J Il y a 21 bits pour le numéro de réseau, soit 2097150 réseaux possibles (221 - 2) et 8 bits pour la
machine, soit 254 machines par réseau.

Q classe D : 1110 pour les quatre premiers bits


J Les adresses de classe D sont des adresses de multicast, c'est à dire des adresses de groupe. Par
exemple, certains routeurs communiquant avec OSPF utilisent une adresse de classe D pour se
reconnaître.

p100
4 - ADRESSAGE IP

NTway.com L'adressage IP
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

• Un adressage corrélé géographiquement


• Des adresses sur 4 octets
• Une notation décimale pointée, exemple : 192.10.95.11
Quatre grandes classes d'adresses
* CLASSE A

7 bits pour le réseau local logique


24 bits pour les stations
1er octet : 1 à 126 ( une division représente un octet)

* CLASSE B

10

14 bits pour le réseau local logique


16 bits pour les stations
1er octet : 128 à 191
* CLASSE C

110
21 bits pour le réseau local logique
8 bits pour les stations
1er octet : 192 à 223

* CLASSE D
1110
28 bits pour des adresses de multicast

p101
4 - ADRESSAGE IP

NTway.com J ADRESSES IP RESERVEES :


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma Q Sur une plage d’adresse, (une plage d'adresse est une suite d'adresse contiguë) l'adresse
la plus haute et l’adresse la plus basse ne sont pas utilisable pour adresser les stations :
J L'adresse la plus "haute" de la plage représentant le réseau.

Q Exemple pour la plage d'adresse 10, l'adresse la plus haute est 10.0.0.0 et représente le
réseau 10.

J L'adresse la plus "basse" de la plage représente un broadcast sur le réseau

Q Exemple pour la plage d'adresse 10, l'adresse la plus basse est 10.255.255.255 et représente
toutes les stations du réseau 10.

J 0.0.0.0 : est utilisé aujourd'hui dans des cas particuliers.


Q Une adresse 0.0.0.0 avec un masque 255.255.255.255 est l'exemple type d'une machine

cliente DHCP qui ne connaît pas son adresse IP.

Q Une adresse 0.0.0.0 avec un masque 0.0.0.0 se trouve dans une table de routage et indique
l'adresse de la passerelle par défaut.

J 127.x.y.z
Q Cette plage d'adresse est réservée au loopback (boucle locale).

Q Elle représente la machine et peut servir à la communication inter processus locale. Un


paquet avec une adresse de destination 127. ne "sort" jamais de la machine IP.

p102
4 - ADRESSAGE IP

NTway.com J ADRESSES DE DIFFUSION (broadcast) :


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Q Une adresse de broadcast est une adresse dans laquelle tout le monde se reconnaît.

Q Il n'existe pas d’adresse de broadcast permettant d’envoyer un paquet IP à toutes les


machines IP de tous les réseaux logiques. En conséquence, il existe deux adresses de
broadcast spécifique :

J Limited Broadcast (diffusion limitée) : tous les bits sont à 1 (notée 255.255.255.255).
Ce type d'adresse permet d'adresser toutes les machines sur le réseau de l'émetteur du paquet.

J Ce broadcast est donc limité par réseau logique IP (il ne franchit pas les routeurs IP).

J LE SUBNETTING

Q Le rapide développement des réseaux TCP/IP, notamment celui de Internet, a entraîné une
exploitation de plus en plus difficile des réseaux en particulier au niveau du routage.

Q L'adressage hiérarchique à un niveau (par le numéro réseau de l'adresse IP) s'est révélé
trop restrictif et trop lourd à gérer lorsqu' un très grand nombre de machines étaient
connectées.

p103
4 - ADRESSAGE IP

NTway.com J LE SUBNETTING (suite)


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Q L'utilisation de l'adressage en sous-réseau oblige à analyser l'adresse unicast IP de façon


différente. Il faut en effet considérer les parties réseau et sous-réseau comme une
information de routage (via le routeur) et la partie machine comme une information
"locale" au réseau/sous-réseau.

Q Il est donc essentiel pour toute machine IP de pouvoir clairement identifier ces 2 parties.

Q Si, extraire la partie réseau peut se faire à partir de l'examen des premiers bits de l'octet de
poids fort, la partie sous-réseau a une longueur variable (en bits), sans restriction sur les
valeurs possibles. Il convient donc de trouver un autre mécanisme de séparation : le
masque.

Q Le masque de sous-réseau (subnet mask) permet de délimiter la fin de la partie


<réseau><sous réseau>. Il est constitué d'une séquence de 1 consécutifs du premier bit de
poids fort de l'adresse jusqu'à la séparation et, d'une séquence de 0 consécutifs sur le
reste (n° de machine). Chaque machine IP doit gérer ce masque.

p104
4 - ADRESSAGE IP

NTway.com J LE SUBNETTING (suite)


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Q Application :

J hypothèse :

adresse réseau de classe B (2octets)

sous-réseau sur 1 octet

n° de machine sur 1 octet

J conclusion :

masque de subnet correspondant 255.255.255.0

nombre de sous-réseau possible 254

nombre de machines par sous-réseaux 254

J exemple numéro de réseau : 128.01

numéro de sous-réseau possibles : 128.01.01 à 128.01.254

numéros de machines possibles/sous-réseau 128.01.x.1 à 128.01.x.254

p105
4 - ADRESSAGE IP

NTway.com J LE SUBNETTING (suite)


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Q Application :

J Il faut noter les adresses réservées suivantes :

limited broadcast 255.255.255.255

directed broadcast 128.01.x.255 avec 1<x<254

ce sous-reseau 128.01.x.0 avec 1<x<254

cette machine dans le (sous) réseau 0.0.0.y avec 1<y<254

p106
4 - ADRESSAGE IP

NTway.com J ADRESSAGE IP PRIVE ET TRANSLATION D'ADRESSE


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Q Espace d'adresses privées : RFC 1918

J L'Autorité d'affectation de Numéros sur Internet (IANA) a réservé les 3 blocs suivant dans l'espace
d'adressage pour des réseaux internes :
Q 10.0.0.0 Î 10.255.255.255
Q 172.16.0.0 Î 172.31.255.255
Q 192.168.0.0 Î 192.168.255.255

J Une entreprise peut décider d'utiliser des adresses à l'intérieur des plages spécifiées dans ce RFC
sans en référer à l'IANA ni à un organisme d'enregistrement.

J Les adresses dans ces plages ne seront uniques qu'à l'intérieur de l'entreprise, ou du groupe
d'entreprises qui décident de se mettre d'accord sur cet espace d'adressage pour être en mesure
de communiquer ensemble dans leur inter-réseau.

Q Dispositif de translation d’adresse : RFC 1631

J La translation d'adresse est le dispositif par lequel une machine possédant une adresse IP non
officielle (le plus souvent) va s'adresser à une autre machine qui va lui fournir une adresse IP
officielle ; issue d'un pool d'adresses officielles qu'elle gère.

J La translation d'adresse est une mécanique très couramment utilisée notamment pour étendre la
durée de vie d'IPV4 (en corrélation avec le RFC 1918) et pour introduire une mécanique de sécurité
des accès à une entreprise.

p107
4 - ADRESSAGE IP

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma La translation d'adresses

Principe :
Entreprise x

1000 postes Monde extérieur


Passerelle
Réseau important possédant des adresses non officielles.
Mais seulement 100 machines sont susceptibles de communiquer avec
l’extérieur.

Idées : L'entreprise x possède une classe C officielle pour ses communications externes

Entreprise x
Adresse officielle 192.93.11.x 192.93.10.5

1000 postes
Adressage privé 10.1.x.y 192.93.11.7 à 192.93.10.5
Passerelle
@ Station 10.1.1.1

10.1.1.1 192.93.11.7

p108
4 - ADRESSAGE IP

NTway.com
Tél: 0-22-22-50-98 La translation d'adresses
E-mail: ntway@iam.net.ma

1 Concept de pool
- si les 100 susceptibles de se connecter à l ’extérieur ne sont
pas toujours les mêmes, il faut travailler en pool.

Piocher / restituer

Quand piocher ?

Quand restituer ?

Cette approche en pool n ’est quasiment pas jouable (sauf si


!
la connexion physique à la passerelle est du type commutée)

p109
4 - ADRESSAGE IP

NTway.com La translation d'adresses


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

2 Le problème du passage de l ’adresse au niveau des applications

FTP FTP
client GW serveur

10.1.1.1 à 192.93.10.5 192.93.11.7 à 192.93.10.5

Connexion à 10.1.1.1 !!!

Le problème est dû au transport d’adresse IP dans les


couches supérieures.

Il peut être réglé en surveillant dans la passerelle certaines


couches supérieures pour y opérer la translation.

p110
4 - ADRESSAGE IP
MODELISATION DU ROUTAGE

NTway.com J MODELISATION DU ROUTAGE


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Q Host1 cherche à atteindre Host2. Pour cela, il doit résoudre trois problèmes :

J 1. Trouver le bon routeur de sortie. Cette opération s'appelle le décollage. Dans les hosts, ce
décollage est statique. Il est configuré "en dur" dans la machine (commande route add) quel
routeur le host 1 doit choisir pour décoller. Si ce routeur tombe en panne, il faut reconfigurer à la
main un nouveau routeur. On verra dans la suite de ce cours, que cette table de routage statique
(association numéro de réseau, adresse IP du routeur à prendre pour l'atteindre), peut être
complétée dynamiquement au moyen des datagrammes ICMP_REDIRECT.

J 2. Trouver le routeur qui dessert le réseau final. Cette opération s'appelle le transit. Un routeur doit
donc avoir une table de routage contenant tous les numéros de réseaux pour lesquels il doit être
capable de faire du transit de datagrammes. Pour éviter une mise à jour manuelle de ces tables, des
échanges automatiques entre routeurs sont possibles et ont été très développés pour TCP/IP, pour
permettre à un réseaux de routeurs IP, en cas de panne de routeur ou de lignes coupées, de profiter
du maillage physique restant pour reconstituer de nouveaux chemins entre réseaux élémentaires,
de façon invisible pour les hosts d'extrémité. Ceci se fait avec des protocoles inter-routeurs (link
state ou distance vector).

J 3. Trouver Host2 sur le réseau d'arrivée. Cette opération s'appelle l'atterrissage. En fait, il s'agit de
trouver une adresse MAC à partir d'une adresse IP. Ceci se fait de façon dynamique, grâce au
protocole ARP décrit dans le chapitre suivant.

p111
4 - ADRESSAGE IP
MODELISATION DU ROUTAGE

NTway.com
Tél: 0-22-22-50-98 Modélisation du routage
E-mail: ntway@iam.net.ma

LA STATION 1 CHERCHE A ATTEINDRE LA STATION 2


STATION 1

STATION 2

Problème 1 : trouver Problème 2 : trouver Problème 3 : trouver


le routeur le routeur destinataire l'élément dans le réseau
de sortie local logique

REMARQUE
Le problème du routage représente 3 étapes successives :
Problème 1 : DECOLLAGE
Problème 2 : TRANSIT
Problème 3 : ATTERRISSAGE

p112
4 - ADRESSAGE IP
MODELISATION DU ROUTAGE

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma F05-116

LE "DECOLLAGE" DANS L'ARCHITECTURE TCP-IP

Telnet Darkvador
Route add Gethostbyname
pour le réseau Lecture du fichier /etc /hosts
194.95.13 -> Darkvador 194.95.13.2
passez par -> Darkvador n'est pas sur le
le routeur 192.93.10.5 même réseau local logique
-> Consultation de route add

192.93.10.1 192.93.10.2 192.93.10.3


255.255.255.0 255.255.255.0 255.255.255.0

192.93.10.4 192.93.10.5
255.255.255.0 255.255.255.0

194.95.13.4 194.95.13.5
255.255.255.0 255.255.255.0

DARKVADOR
194.95.13.1 194.95.13.2 194.95.13.3
255.255.255.0 255.255.255.0 255.255.255.0

Le décollage est statique (route add)


La requête ARP pour trouver l'adresse MAC du routeur de sortie
n'est qu'un détail, sauf
-> problème de sécurité : une autre machine peut répondre à la
requête ARP
-> en cas d'indisponibilité du routeur 192.93.10.5, le
back-up est statique (reconfiguration du route add sur chaque host)

p113
4 - ADRESSAGE IP
MODELISATION DU ROUTAGE

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
"L'ATTERRISSAGE" SANS DECOLLAGE

PIRATE !

192.93.10.1 192.93.10.2 192.93.10.3

qui a l'adresse MAC correspondant à


l'adresse IP 192.93.10.3 ?

c'est moi

OK, voici les


données IP

Solution : table statique

F05-118

p114
4 - ADRESSAGE IP
MODELISATION DU ROUTAGE

NTway.com
Tél: 0-22-22-50-98 F05-099B
E-mail: ntway@iam.net.ma LE ROUTAGE DANS IP

HOST HOST
SOURCE DESTINATAIRE
PROTOCOLES LINK STATE
OU DISTANCE VECTOR

QUEL EST LE MEILLEUR


ITINERAIRE POUR CE
DATAGRAMME ?

TELNET SKYWALKER QUELLE EST L'ADRESSE


-> GETHOSTBYNAME MAC DE L' ADRESSE
-> LECTURE DE /ETC/HOSTS POUR IP DESTINATAIRE ?
TROUVER L'ADRESSE IP DE -> ARP
SKYWALKER

Etapes
TROUVER L'ADRESSE IP DU HOST DESTINATAIRE.
- SI L'ADRESSE IP DU RESEAU LOCAL LOGIQUE DU HOST DESTINATAIRE EST EGALE A MA
PROPRE ADRESSE RESEAU, ALORS REQUETE ARP (ATTERRISSAGE SANS DECOLLAGE),
- SI L'ADRESSE IP DU RESEAU LOCAL LOGIQUE DU HOST DESTINATAIRE EST DIFFERENTE DE
MA PROPRE ADRESSE RESEAU, ALORS :
-> DECOLLAGE
-> TROUVER L'ADRESSE IP DU ROUTEUR DE SORTIE(ROUTE ADD)
-> TROUVER L'ADRESSE MAC DU ROUTEUR DE SORTIE (ARP)
-> ATTENTION! LE DECOLLAGE EST STATIQUE!

p115
4 - ADRESSAGE IP
MODELISATION DU ROUTAGE

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
EXERCICES SUR LE ROUTAGE

Cas 1 :

@IP A B C D
PONT

@MAC
x y z t v w

Cas 2 :
E F
@IP A B ROUTEUR C D

@MAC x y z t v w

Le host A veut communiquer avec le host D.


Dans le MAC PDU, on demande :

pont pont routeur routeur


sortie de A entrée dans D sortie de A entrée dans D
@MAC source
@MAC dest
@IP source
@IP dest
F05-086

p116
NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

-5-
LE PROTOCOLE ARP / RARP

p117
5 - LE PROTOCOLE ARP / RARP

NTway.com J OBJECTIF DU PROTOCOLE


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Q Le protocole ARP (Address Resolution Protocol) est destiné à permettre à un usager de


réseau (LAN à priori) de connaître l'adresse réseau d'un utilisateur donné afin d'éviter
l'existence de tables statiques chez chaque utilisateur.

Q Le problème : MACSAP = f(NSAP/NET), soit, à partir d'une adresse de niveau 3, trouver une
adresse de niveau 2.

J Le critère de recherche peut être l'adresse d'un utilisateur (NSAP, c'est à dire adresse INTERNET de
HOST), mais aussi le NET d'une passerelle (adresse INTERNET de GATEWAY).

La solution est fondée sur l'usage de deux datagrammes :

(@MAC1, @IP1) (@MACx, @IPx) (@MACy, @IPy) (@MACz, @IPz) ....

[@M1 --> Tous] ARP_REQ (@INTERNET Iy?)

[@My --> @M1] ARP_RESP

[@MAC1 --> @My] IP_DGRAM (pour @Iy)

L'émetteur peut ainsi déterminer le MACSAP cherché en regardant l'adresse source de la réponse
F05-006

p118
5 - LE PROTOCOLE ARP / RARP

NTway.com Q Le protocole doit être capable de traiter différents problèmes :


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

J Il doit fonctionner sur d'autres réseaux que ETHERNET ==> le format prévoira des tailles d'adresses
MAC quelconques. Il pourra de même accepter des adresses NSAP quelconques (autres que
INTERNET)
J Il serait intéressant également qu'il puisse permettre à un tiers de fournir l'adresse MAC d'un de ses
voisins qui ne saurait pas gérer le protocole. Pour atteindre un tel objectif, il est alors nécessaire de
mettre explicitement dans la réponse l'adresse MACSAP cherchée (pour permettre une
différenciation entre l'adresse MAC du répondeur et l'adresse MAC cherchée).

Usage d'un serveur d'adresses :

(@MAC1, @IP1) (@MACx, @IPx) (@MACy, @IPy) (@MACz, @IPz) ....

[@M1 --> Tous] ARP_REQ (@INTERNET Iy?)

[@Mz --> @M1] ARP_RESP (@MAC y)

[@M1 --> @My] IP_DGRAM (pour @Iy)

L'émetteur peut ainsi déterminer le MACSAP cherché en regardant l'adresse indiquée dans la réponse, quelle que soit l'adress
physique du répondeur. F05-008

p119
5 - LE PROTOCOLE ARP / RARP

NTway.com Q De plus, il est possible d'imaginer un perfectionnement dans lequel des stations non
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma concernées puissent néanmoins être à l'écoute du réseau et exploiter des réponses ARP
qui ne leur sont pas destinées, afin d'augmenter leur propre connaissance des
destinataires présents sur le réseau. Mais alors, il devient opportun d'inclure également
dans la réponse l'adresse INTERNET qui était demandée (afin d'éviter à ces stations d'avoir
à écouter également les requêtes et à les mémoriser pour les corréler. Ce processus est
rare car il suppose la capacité d'une station à lire les messages qui ne lui sont pas
adressés.

Exploitation par un tiers des réponses ARP :

(@MAC1, @IP1) (@MACx, @IPx) (@MACy, @IPy) (@MACz, @IPz) ....

[@M1 --> Tous] ARP_REQ (@INTERNET Iy?)

[@My --> @M1] ARP_RESP (@My, @Iy)

[@Mx --> @My] IP_DGRAM (pour @Iy)

F05-009

p120
5 - LE PROTOCOLE ARP / RARP

NTway.com Q Cependant, cette exploitation suppose que la requête ARP contienne également l'adresse
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma INTERNET du requérant. Pour des raisons d'homogénéité, l'adresse MAC du requérant est
également fournie dans le datagramme.

Exploitation par un tiers des réponses ARP :

(@MAC1, @IP1) (@MACx, @IPx) (@MACy, @IPy) (@MACz, @IPz) ....

[@M1 --> Tous] ARP_REQ (@M1, @I1, ???, @Iy)

[@My --> @M1] ARP_RESP (@My, @Iy, @M1, @I1)

[@M1 --> @My] IP_DGRAM (pour @Iy)

[@Mx --> @M1] IP_DGRAM (pour @I1)

F05-010

Q Cette caractéristique offre également l'avantage d'éviter toute corrélation entre requête et
réponse dans la gestion de l'émetteur, puisque la réponse contient toutes les informations
dont il a besoin. Tout au plus doit-il gérer un timer lui permettant de répéter la requête si
son besoin n'est pas satisfait dans un délai localement jugé raisonnable.

p121
5 - LE PROTOCOLE ARP / RARP

Un grand nombre d'autres raffinements sont imaginables : Il est ainsi possible d'imaginer
NTway.com Q

qu'une station venant de démarrer sur le réseau et n'étant ainsi probablement pas connue
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma de ses voisins puisse se signaler spontanément en émettant par exemple une requête ARP
contenant ses adresses, ou, mieux, en émettant spontanément une réponse ARP
broadcast contenant ses propres adresses pour permettre à tous ceux qui exploitent les
réponses de mettre à jour leurs propres tables d'adresses.

J Problèmes posés par ARP :

Q Un évident problème de sécurité existe si une machine du réseau veut se faire passer pour
une autre :

Problème de sécurité posé par l'usurpation d'adresse via ARP :

(@MAC1, @IP1) (@MACx, @IPx) (@MACy, @IPy) (@MACz, @IPz) ....


D O W N !!! MALHONNETE !!!
[@M1 --> Tous] ARP_REQ (@M1, @I1, ???, @Iy)

[@Mz --> @M1] ARP_RESP (@Mz, @Iy, @M1, @I1)

[@M1 --> @Mz] IP_DGRAM (pour @Iy)

F05-011

p122
5 - LE PROTOCOLE ARP / RARP

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Q Un autre problème est la gestion du droit à répondre pour un tiers (normalement interdit,
sauf serveur d'adresse);

Q Un troisième problème est la pérennité de l'information ainsi acquise en cas de disparition


de la machine concernée et de reprise avec une autre adresse (traitement, par exemple, de
la panne de coupleur ETHERNET et son remplacement rapide. Aucune règle précise n'est
imposée, mais il est fortement recommandé de gérer un timer interne de validité
d'information à l'épuisement duquel une requête ARP de "regénération" doit être émise.

p123
5 - LE PROTOCOLE ARP / RARP

NTway.com Q Un autre problème de nature comparable se présente lorsque certaines machines, dites
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma "diskless", sans disques, cherchent pour alimenter leurs tables internes à connaître leur
propre adresse NSAP (IP, par exemple). Elles sont capables de connaître leurs adresses
physiques (ETHERNET, par exemple) par analyse de son coupleur hardware. Le protocole
utilisé dans ce cas s'appelle RARP (Reverse Address Resolution Protocol) et utilise
exactement les mêmes PDU que ARP (aux codes près).

Usage du protocole RARP pour connaître sa propre adresse INTERNET :

(@MAC1, ???) (@MACx, @IPx) (@MACy, @IPy) (@MACz, @IPz) ....


RARP_SERVER
[@M1 --> Tous] RARP_REQ (@M1, ??? , @M1, ???)

[@Mz --> @M1] RARP_RESP (@M1, @I1, @M1, ???)

ou celle d'un voisin sur le réseau :

(@MAC1, ???) (@MACx, @IPx) (@MACy, @IPy) (@MACz, @IPz) ....


RARP_SERVER
[@M1 --> Tous] RARP_REQ (@M1, ??? , @Mx, ???)

[@Mz --> @M1] RARP_RESP (@Mx , @Ix , @M1, ???)

F05-012

p124
5 - LE PROTOCOLE ARP / RARP

NTway.com J Le PROXY ARP.


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Q Il est également possible d'imaginer qu'une passerelle puisse répondre en donnant sa


propre adresse si elle sait qu'elle est capable de router vers le vrai destinataire : Il s'agit
d'une utilisation du protocole ARP appelée PROXY ARP.

Usage du PROXY ARP :

(@MAC1, @IP1) (@MACx, @IPx) (@MACy, @IPy) < autre LAN > (@MACz, @IPz)

[@M1 --> Tous] ARP_REQ (@INTERNET Iz?)

[@My --> @M1] ARP_RESP

[@M1 --> @My] IP_DGRAM (pour @Iz) [@My --> @My] IP_DGRAM (pour @Iz)

L'émetteur ne sait pas en réalité que deux réseaux physiques existent. Le deuxième réseau est masqué par le premier.
F05-007

Q Dans ce cas, l'émetteur de la requête ARP ne soupçonne pas l'existence de deux sous-
réseaux locaux logiques. C'est l'intermédiaire qui prend en charge le réacheminement des
requêtes.

p125
5 - LE PROTOCOLE ARP / RARP

NTway.com J Le codage du protocole.


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Q Rappel : Le packet_type ARP est 0x0806, le packet_type RARP est 0x8035.

Structure d'un datagramme ARP (packet_type 0806) ou RARP (packet type 8035)
(chaque division représentant un octet)
H P
Hardware Protocol
L L Datagramm Sender Sender Target Target
code code
E E code @Macsap @Prot @Macsap @Prot
N N

Hardware Code : identification de la nature des adresses MAC, 0001= ETHERNET


Protocole Code : identification de la nature des adresses protocolaires, 0800=IP
HLEN : longueur en octets des adresses MAC (6 pour ETHERNET)
PLEN : longueur en octets des adresses protocolaires (4 pour adresses IP)
Datagramm Code : 0001 = ARP_REQ
: 0002 = ARP_RESP
: 0003 = RARP_REQ
: 0004 = RARP_RESP
Sender @Macsap : adresse Mac du demandeur (toujours présente)
Sender @Prot : adresse protocolaire du demandeur
Target @Macsap : adresse MAC de la cible
Target @Prot : adresse protocolaire cible (@Ix, 00 pour RARP)
F05-013

p126
5 - LE PROTOCOLE ARP / RARP

NTway.com J Le codage du protocole.


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Q Exemple de codage ARP :

Trame échangées :

FF FF FF FF FF FF 08 00 20 02 45 9E 08 06 00 01 08 00 06 04 00
01 08 00 20 02 45 9E 81 68 FE 06 00 00 00 00 00 00 81 68 FE 05

08 00 20 02 45 9E 08 00 20 07 0B 94 08 06 00 01 08 00 06 04 00
02 08 00 20 07 0B 94 81 68 FE 05 08 00 20 02 45 9E 81 68 FE 06

Interprétation :

F05-014

p127
5 - LE PROTOCOLE ISO 9542

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
LE PROTOCOLE ISO 9542 ( OU ROUTAGE ES-IS )

le PDU passe
deux fois sur le LAN,
je dois rediriger.
RD_PDU( B,y )

ES ES ES IS
@NSAP A B C D D : Network
Entity Title

@MACSAP x y z t

ESH_PDU( A,x ) ISH_PDU( D,t )


all IS all ES

Adresse de multicast all IS : 09002B000005


Adresse de multicast all ES : 09002B000004

Remarques
- Génération de trafic des ESH_PDU et des ISH_PDU.
- Dans l'implémentation de ES to IS 9542, il est possible pour un ES
de se reconnaître dans les deux adresses de multicast.
- Ce protocole est adapté au décollage comme à l'atterrissage.
- Attention! une première version des recommandations GOSIP avait
inversé les deux adresses. Il existe donc des machines avec
l'ancienne affectation.
- Le fonctionnement par émission spontanée est nécessaire car
l'adressage de niveau 3 OSI est non corrélé géographiquement.

F05-085

p128
5 - LE PROTOCOLE ISO 9542

NTway.com J Relations avec l'ISO.


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Q Le protocole OSI le plus proche est en fait le protocole ISO 9542 (appelé quelquefois
routage ES-IS) dont le rôle est de permettre à une passerelle de connaître les @NSAP
gérés sur son réseau et les @MACSAP qui les supportent. ISO 9542 permet également à un
host sur un réseau de connaître les adresses des passerelles supposées capables de
router ses datagrammes.

Q Le protocole ISO 9542 est fondé sur peu de NPDU :

J ESH_PDU permet à un host (End System) de signaler (par multicast) à son réseau, et donc aux
passerelles qui sont dessus, les NSAP supportés par le Host. Les passerelles peuvent ainsi
alimenter leurs tables (NSAP, MACSAP);
J ISH_PDU permet à une passerelle (Intermediate System) de signaler son existence par multicast
aux hosts de son réseau.
J RD_PDU permet à une passerelle de fournir à un host de son réseau l'adresse MACSAP exacte d'un
autre Host du réseau que le premier cherchait à atteindre via la passerelle.

Q Des mécanismes complémentaires normalisés sont prévus pour gérer la pérennité des
informations dans les RIB (Routing Information Base).

p129
NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

-6-
LE PROTOCOLE IP

p130
6 - LE PROTOCOLE IP

NTway.com J OBJECTIFS
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Q Le protocole Internet est destiné à interconnecter des réseaux indépendants et


hétérogènes.

Q Les principaux critères retenus par le département de la défense Américaine étaient les
suivants :

J Utilisation avec des réseaux hétérogènes,


J Service à datagrammes,
J Utilisation pour des communications stratégiques,
J Haute fiabilité même en environnement hostile,
J Transport de données,

J Services répartis

Q Les termes consacrés étaient : Unreliable, best-effort, connectionless

p131
6 - LE PROTOCOLE IP

CARACTERISTIQUES
NTway.com J

Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma J Protocole à datagrammes indépendants,

J Les noeuds peuvent détruire les datagrammes s'ils manquent de ressources,

J Pas de correction de perte de datagrammes,

J Segmentation et réassemblage des datagrammes si des réseaux physiques intermédiaires le


nécessitent,

J Pas de garantie d'acheminement des datagrammes (pas d'ACK),

J Pas de garantie de maintien du séquencement des datagrammes,

J Techniques de contrôle de flux très limitées n'évitant pas les pertes de datagrammes sur
congestion,

J Destruction des datagrammes ayant transité trop longtemps dans le réseau,

J Nombreuses options pour assurer certaines fonctions spécifiques (sécurité, choix d'un chemin
particulier ...).

La grande propriété des réseaux IP est de pouvoir se reconfigurer automatiquement en cas


de rupture topologique pour offrir de nouveaux chemins aux hôtes d'extrémité, en utilisant
le maillage physique restant.
p132
6 - LE PROTOCOLE IP

ELEMENTS PROTOCOLAIRES
NTway.com J

Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma Q Le protocole IP ne comprend qu'un seul PDU (IP_DGRAM) transportant les données du
niveau supérieur (ou leurs morceaux).

( chaque division représente 1 bit)

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

Version header Type de service Longueur totale en octets


length

Identification Flags Offset dans le NSDU (fragment)

TTL = durée de vie Protocole Checksum


transporté

Adresse IP source (émetteur)

Adresse IP destinataire

Champ Options

[Padding]

Champ Data (segment de niveau supérieur)

F05-015

p133
6 - LE PROTOCOLE IP

ANALYSE DES DIFFERENTS CHAMPS


NTway.com J

Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma Q Le protocole IP ne comprend qu'un seul PDU (IP_DGRAM) transportant les données du
niveau supérieur (ou leurs morceaux).

J Champ Version :

Q Taille : 4 bits.

Q Abréviation : VER.

Q Valeur : Identification de la version courante du protocole. Ce document décrit la version 4.

J Champ Header Length :

Q Taille : 4 bits.

Q Abréviation : IHL.

Q Valeur : longueur de l'entête IP (y compris la partie options) exprimée en mots de 32 bits.

La valeur minimale de ce champ est 5.


La valeur maximale est 15, ce qui limite la taille du champ options à 10 mots, soit 40 octets.

p134
6 - LE PROTOCOLE IP

Champ Type de Service :


NTway.com J

Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Q Taille : 8 bits.

Q Abréviation : TOS.

Q Valeur : b0 b1 b2 b3 b4 b5 b6 b7
b0 b1 b2 (PRECEDENCE) décrit la priorité :
111 Contrôle du réseau
110 Contrôle inter-réseaux
101 CRITIC/ECP
100 Flash prioritaire
011 Flash
010 Immédiat
001 Prioritaire
000 Routine
b3 (Delay) décrit le souhait en matière de temps de traversée
0 traversée normale
1 privilégier les chemins à temps de traversée faible
b4 (Throughput) décrit le souhait en matière de débit
0 débit normal
1 privilégier les chemins à débit élevé
b5 (Reliability) décrit le souhait en matière de fiabilité
0 fiabilité normale
1 privilégier les chemins à fiabilité élevée
b6 b7 : RFU
Attention au fait que ces champs ne sont significatifs que dans la mesure où les
passerelles utilisées dans la traversée du réseau les interprètent et les respectent, ce qui
est très rarement le cas. La valeur standard de ce champ est donc en général 0x00.
p135
6 - LE PROTOCOLE IP

Champ Longueur totale :


NTway.com J

Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Q Taille : 16 bits.

Q Abréviation : TL.

Q Valeur : Longueur totale du datagramme, exprimée en octets, header et données inclus. En


cas de fragmentation, ce champ contient la longueur du datagramme courant, c'est à dire
la portion du datagramme initial.

La taille totale d'un datagramme n'est pas limitée par le standard IP (à part la limitation à 16
bits du champ longueur). Cependant, il est reconnu que beaucoup de machines sont
susceptibles d'avoir leurs propres limitations.

Q Aussi est-il communément admis que tout le monde doit gérer des datagrammes
(fragmentés ou non) de 576 octets. Au delà, il est recommandé de s'assurer que son
correspondant sait gérer sans anomalies de grandes longueurs.
Q Comme un entête IP standard est de 20 octets, de même qu'un entête TCP est de l'ordre de
20 octets, le chiffre de 576 est raisonnable pour transporter des blocs applicatifs (couches
élevées) de 512 octets, augmentés des entêtes IP, TCP et autres.

p136
6 - LE PROTOCOLE IP

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

IP : LE MECANISME DE SEGMENTATION

4
NSDU = TCP_PDU

IP

* * *
MF = 1 MF = 1 MF = 0
FO = 0 FO = x FO = y
*
= identification

Remarques

Segmentation ==> - Détection de la segmentation


- Numérotation des segments
- Réassemblage et reséquencement des segments

}
d'où le flag MF ( More Fragment )
le champ FO ( Fragment Offset ) dans l'en-tête protocolaire
le champ identification de IP

F05-089

p137
6 - LE PROTOCOLE IP

Champ Identification :
NTway.com J

Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma Q Taille : 16 bits.
Q Abréviation : ID.
Q Valeur : Quelconque. Ce champ identifie (en association avec les champs adresses et
protocoles) le datagramme initial lors de son envoi. Le seul usage de ce champ est donc
de permettre à une entité réceptrice de reconnaître les datagrammes qui appartiennent à
un même datagramme initial et qui doivent donc faire l'objet d'un réassemblage.
Une mauvaise gestion de ce champ peut entraîner une confusion entre deux datagrammes
initiaux ayant été fragmentés et dont les fragments ont été mélangés.

J Champ Flags :

Q Taille : 3 bits.
Q Abréviation : Néant.
Q Valeur : 3 bits [b0 b1 b2] gérant la fragmentation.
B0 RFU, doit rester à 0
b1 DF, (DON'T FRAGMENT) pour interdire la fragmentation
b2 MF, (MORE FRAGMENT) pour signifier des fragments à suivre.

p138
6 - LE PROTOCOLE IP

Champ Offset dans le NSDU initial :


NTway.com J

Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Q Taille : 13 bits.

Q Abréviation : FO (Fragment Offset).

Q Valeur : Position relative (en unités de 8 octets) des DATA contenus dans ce datagramme
par rapport au début des DATA du datagramme initialement envoyé. Seuls un datagramme
complet ou un premier datagramme d'un datagramme fragmenté peuvent avoir ce champ à
0.
Afin de préserver l'intégrité du datagramme initial en cas de fragmentations successives,
ce champ doit être pris en compte comme base dans le calcul des offset des fragments de
fragments (voir exemple ci après).

Q Le concept de fragmentation :

Q La fragmentation est une caractéristique obligatoire (en réception). Un host ne devrait pas
avoir à fragmenter en émission au niveau IP, laissant ce soin aux passerelles
intermédiaires. Cependant, un émetteur sait toujours imposer la non-fragmentation (au
risque d'un rejet intermédiaire au moyen du bit DF (DON'T FRAGMENT)

Q Le réassemblage se fait à destination (sauf entente secrète entre passerelles adjacentes) et


il est entendu qu'un fragment est re-fragmentable.

Q Des fragments de datagramme peuvent ne pas suivre les mêmes routes et peuvent donc se
doubler. La reconnaissance du besoin de réassemblage se fait par analyse des champs
FO, DF, MF.

p139
6 - LE PROTOCOLE IP

En cas de perte de fragment, (détectée par des Timers internes à la couche IP), la totalité
NTway.com Q

du datagramme initial est ignorée, bien évidemment.


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Q Règle LAMARTINE : "Un seul être vous manque et tout est dépeuplé ..."

J Champ Durée de vie :

Q Taille : 8 bits.

Q Abréviation : TTL.

Q Valeur : Quelconque (de 0 à 255).


Cette valeur est décrémentée à chaque traversée de passerelle. Tout intermédiaire ou
destinataire qui détecte le passage à 0 de ce champ est supposé écarter le datagramme et
renvoyer un datagramme ICMP à l'émetteur contenant notamment l'en-tête du datagramme
détruit.
Cette procédure est destinée à éviter les boucles ou cheminements trop anormaux,
permettant ainsi de garantir une durée de vie maximale à un datagramme.
Une telle garantie peut être exploitée pour limiter dans les machines extrémités les durées
de gel de réutilisation de certains paramètres (ou numéros).
En cours de réassemblage, une machine réceptrice est sensée décrémenter ce champ
toutes les secondes environ pour les datagrammes composant le datagramme initial, tant
que tous les datagrammes "fragments" ne sont pas arrivés.
Dans ce cas, ce champ est considéré comme un time_out de réassemblage.

p140
6 - LE PROTOCOLE IP

Champ Protocole :
NTway.com J

Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Q Taille : 8 bits.

Q Abréviation : PROT.

Q Valeur : Identification du protocole supporté au dessus.


0x00 RFU
0x01 ICMP (INTERNET CONTROL MESSAGE)
0x02 IGMP (INTERNET GROUP MULTICAST)
0x03 GGP (GATEWAY to GATEWAY PROTOCOL)
0x05 ST (STREAM)
0x06 TCP (TRANSMISSION CONTROL PROTOCOL)
0x08 EGP (EXTERIOR GATEWAY PROTOCOL)
0x09 IGP (INTERIOR GATEWAY PROTOCOL)
0x0B NVP (NETWORK VOICE PROTOCOL)
0x0C PUP (PARC UNIVERSAL PACKET PROTOCOL)
0x11 UDP (USER DATAGRAM PROTOCOL)
0x14 HMP (HOST MONITORING PROTOCOL)
0x16 XNS-IDP (XEROX INTERNET DATAGRAM)
0x1B RDP (RELIABLE DATA PROTOCOL)
0x1C IRTP (INTERNET RELIABLE TRANSACTION)
0x1D ISO-TP4
0x1E NETBLT (BULK DATA TRANSFER)

Q Voir le fichier /etc/protocols

p141
6 - LE PROTOCOLE IP

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

SEGMENTATION - REASSEMBLAGE : EXERCICE

HOST
SEGMENTATION
SOURCE DANS CE ROUTEUR

HOST
DESTINATAIRE

Question

Qui peut réassembler le datagramme IP ?

F05-098A

p142
6 - LE PROTOCOLE IP

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

SEGMENTATION - REASSEMBLAGE : EXERCICE

HOST
SEGMENTATION
SOURCE DANS CE ROUTEUR

HOST
DESTINATAIRE

Réponse
Seulement le host destinataire, car un même routeur n'est pas
censé voir passer tous les segments issus d'un même datagramme
(mode non connecté).

F05-098B

p143
6 - LE PROTOCOLE IP

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Exemple de fragmentation normale :

Réseau 1 , taille maximale = 1000 Réseau 2, taille maximale = 200

IHL =5, DF, MF, TL = 450, FO = 0


IHL = 5, DF, MF, TL = 196, FO = 0

IHL = 5, DF, MF, TL = 196, FO = 22

IHL = 5, DF, MF, TL = 98, FO = 44

F05-016

p144
6 - LE PROTOCOLE IP

NTway.com
Tél: 0-22-22-50-98 Exemple de double fragmentation normale :
E-mail: ntway@iam.net.ma

Réseau 2, taille maximale = 800 Réseau 3, taille maximale = 200

IHL=5,DF,MF,TL=1000,FO=0

IHL=5,DF,MF,TL=796,FO=0

IHL=5,DF,MF,TL=196,FO=0

IHL=5,DF,MF,TL=196,FO=22

IHL=5,DF,MF,TL=196,FO=44

IHL=5,DF,MF,TL=196,FO=66

IHL=5,DF,MF,TL=92,FO=88
IHL=5,DF,MF,TL=224,FO=97

IHL=5,DF,MF,TL=196,FO=97

IHL=5,DF,MF,TL=48,FO=119

F05-017

p145
6 - LE PROTOCOLE IP

Champ Checksum :
NTway.com J

Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Q Taille : 16 bits

Q Abréviation : Néant.

Q Valeur : Le checksum considéré ne concerne que le header IP ET NON LES DATA!. Il est
destiné à protéger contre les erreurs de transmission au niveau de l'entête. Si un
checksum est nécessaire au niveau des DATA, ce sera le rôle de la couche supérieure de
traiter ce contrôle.

Q En cas d'erreur de checksum, le datagramme est ignoré et un message de contrôle ICMP


sera renvoyé à l'émetteur.
Le calcul est fait en tenant compte d'un champ CHECKSUM initial de 0x0000 et en
additionnant les mots de 16 bits du header un à un modulo 65535
Q Attention : Les sommes se font modulo 65535 et non 65536!. Cette technique de calcul est
appelée arithmétique "complément à 1", par opposition à l'arithmétique "complément à 2"
traditionnelle (modulo 65536). Une particularité de cette arithmétique est d'avoir deux zéros :
0x0000 (quelquefois appelé zéro positif) et 0xFFFF (quelquefois appelé zéro négatif).

Q Le checksum est alors le complément à un (ou l'inverse) de la somme ainsi trouvée.

Q Cette méthode permet de contrôler le checksum en faisant d'un seul coup la somme
modulo 65535 de tous les mots du header et de vérifier qu'elle donne 0xFFFF (ou 0x0000).

p146
6 - LE PROTOCOLE IP

Champ Checksum :
NTway.com J

Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Q Exemple de calcul de Checksum :

Header : 45 00 00 54 8B FE 00 00 FF 01 XX XX 81 68 FE 06 81 68 FE 05
4500 + 0054
= 4554 + 8BFE
= D152 + 0000
= D152 + FF01
= 1D053
= D054 + 8168
= 151BC
= 51BD + FE06
= 14FC3
= 4FC4 + 8168
= D12C + FE05
= 1CF31
= CF32
Le checksum est alors le complément à 1 de CF32, soit 30CD.

Q A noter : Cette méthode de checksum est relativement faible (bien que jugée satisfaisante)
et ne permet pas par exemple de détecter des inversions de bytes de mêmes positions (ou
de mots). Cette faiblesse a été corrigée dans la méthode choisie en ISO TP4 (où le
checksum est composé de deux bytes C0=SIGMA(bytei) et C1=SIGMA(i*bytei).

p147
6 - LE PROTOCOLE IP

Champ Adresse source :


NTway.com J

Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Q Taille : 32 bits.

Q Abréviation : SOURCE.

Q Valeur : Adresse IP origine.


Attention : En cas de HOST multi réseaux, l'adresse fournie est celle qui correspond au
réseau par lequel le datagramme sort.

J Champ Adresse destinataire :

Q Taille : 32 bits.

Q Abréviation : DEST.

Q Valeur : Adresse IP destinataire.

J Champ Options :

Q Taille : Variable, de 0 à 40 octets. La longueur effective de la partie option est 4*(IHL-5)


octets.

p148
6 - LE PROTOCOLE IP

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
J Analyse du champ option :

Q Le champ est constitué d'une succession d'options élémentaires de longueurs variables.

Q Chaque option élémentaire est elle-même constituée :

J Soit d'un seul octet (options de longueur fixe),


J Soit d'un octet définissant l'option, suivi d'un octet de longueur et des DATAs de l'option.

Q Longueur totale de l'option, exprimée en octets, y compris les deux octets type et
longueur. Ce champ vaut donc au minimum 2.

Q Le champ option doit être complété de façon à se terminer sur une limite de 32 bits (la
taille du header est d'ailleurs exprimée en multiples de 32 bits).

p149
6 - LE PROTOCOLE IP

NTway.com
Tél: 0-22-22-50-98 J Analyse du champ option :
E-mail: ntway@iam.net.ma

Format du champ option

Option Option Option Option Padding


1 2 i k éventuel

Une option peut être constituée d'un seul octet :


(les divisions correspondent à des positions binaires)

b0 b0 b0 b0 b4 b5 b6 b7

CF classe numéro

Une option peut aussi être constituée de plusieurs octets :


(les divisions correspondent à des positions binaires)

b0 b0 b0 b0 b4 b5 b6 b7 b0 b0 b0 b0 b4 b5 b6 b7

CF classe numéro longueur totale valeur ...

Le bit CF (Copy Flag) définit la possibilité de copier l'option dans les en-têtes des datagrammes résultant éventuellement
d'une fragmentation du datagramme courant.
CF à 0 Interdit la copie : l'option n'est reconduite que dans le datagramme de tête,
CF à 1 Autorise la copie dans tous les datagrammes.

F05-018

p150
6 - LE PROTOCOLE IP

NTway.com J Analyse du champ option :


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Q Différentes classes d'options :

J 0 Contrôle (sécurité, routage, ...)


J 1 RFU
J 2 Debug et mesures
J 3 RFU

Q Différentes options de la classe 0 :

J 0 Fin d'options (option tenant sur un octet)


J 1 NOP (option tenant sur un octet), sans effet
J 2 Sécurité
J 3 Routage approximatif (LOOSE SOURCE ROUTING)
J 7 Enregistrement de la route prise.
J 8 Identification de stream.
J 9 Routage impératif (STRICT SOURCE ROUTING)

Q Différentes options de la classe 2 :

J 4 Marquage de date.

p151
6 - LE PROTOCOLE IP

NTway.com J Présentation et codage des principales options IP :


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Q Option 0 (Fin d'option)

J Format : Longueur fixe d'un octet

J Classe : 0 (Contrôle)

J Rôle : Terminer l'analyse des options.

Q Option 1 (NOP)

J Format : Longueur fixe d'un octet

J Classe : 0 (Contrôle)

J Rôle : Aucun, à sauter.

p152
6 - LE PROTOCOLE IP

NTway.com Q Option 2 (Sécurité)


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
J Format : Variable

J Classe : 0 (contrôle)

J Rôle : Permet de fournir aux équipements qui les traitent les informations de sécurité
initialement prévues par le DOD.

J Valeur : Elle est composée de 4 champs consécutifs (sur 9 octets)


S (Sécurité) sur 16 bits codant de non classifié à top secret
C (Compartimentage) sur 16 bits
H (Handling restriction) sur 16 bits
TCC (Transmission Control Code) sur 24 bits

Q Option 3 (Routage approximatif)

J Format : Variable

J Classe : 0 (contrôle)

J Rôle : Permet de mentionner une liste d'adresses IP de passerelles que l'on voit traverser
dans l'ordre où elles sont mentionnées. Le routage est dit "approximatif" car chaque passerelle
peut choisir d'accéder à la suivante dans la liste par un chemin quelconque passant éventuellement
par d'autres passerelles intermédiaires.

J Valeur : Un octet utilisé comme pointeur dans l'option vers l'adresse de la prochaine passerelle à
atteindre. Ce pointeur est relatif au début de l'option et sa plus petite valeur possible est donc 4.

Une liste d'adresses de passerelles (sur 4 octets chaque).

p153
6 - LE PROTOCOLE IP

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Q Le fonctionnement de cette option est simple à un détail près : chaque passerelle utilise la
liste en option pour vérifier si elle est la prochaine visée. Si ce n'est pas le cas, elle
commute le datagramme vers la prochaine passerelle dans la liste. Si c'est le cas, elle fait
bouger le pointeur pour viser la suivante, mais en ayant modifié au préalable le contenu du
champ option en remplaçant sa propre adresse par l'adresse qu'elle possède dans le
réseau de sortie, ceci afin de permettre au récepteur, s'il le souhaite, d'utiliser la liste ainsi
constituée pour le chemin de retour.
Remarque : Cette option est toujours copiée en cas de fragmentation (bit CF toujours à 1).

Q Ce qui signifie qu'un datagramme pris au hasard dans un réseau n'est pas nécessairement
en transit vers l'adresse indiquée dans le champ DEST, mais peut-être vers l'adresse
présente dans le champ option comme prochaine entrée dans la liste!

Q Ce problème a été résolu dans les protocoles OSI (ISO 8473) en introduisant une
distinction très claire entre les @NSAP de hosts (adresses de Network Service Access
Point de ES) et les @NET de passerelles (Adresses de Network ENtities de IS), distinction
qui n'existe pas dans l'architecture TCP-IP où la confusion règne entre ces deux concepts.

p154
6 - LE PROTOCOLE IP

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

EXERCICE : LES OPTIONS DE IP

3.1
2.2 R R 4.1
3.2 4.2
Host 2.1 Host
R R
1.2 5.1
1.1 5.2

Question

Dans le cadre de l'option Route Recording ( enregistrement de la route


prise par un datagramme ), enregistre-t-on les adresses d'entrée, les
adresses de sortie, ou les deux, lorsque le NPDU passe dans un
routeur?

F05-090A

p155
6 - LE PROTOCOLE IP

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

EXERCICE : LES OPTIONS DE IP

3.1
2.2 R R 4.1
3.2 4.2
Host 2.1 Host
R R
1.2 5.1
1.1 5.2

Réponse

Uniquement les adresses de sortie car ce sont les seules intéressantes


et nécessaires pour reprendre le même chemin en sens inverse.

F05-090B

p156
6 - LE PROTOCOLE IP

NTway.com Fonctionnement de l'option Routage approximatif :


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

HOST HOST
1 2

@AH1 @FH2

réseau réseau réseau réseau réseau réseau


A B C D E F

Adresse IP @AG1 GW1 @BG1 @BG2 GW2 @CG2 @CG3 GW3 @DG3 @DG4 GW4 @EG4 @EG5 GW5 @FG5

Datagrame émis par HOST1 et reçu par GW1 : SOURCE = @AH1


DEST = @FH2
OPTION = 0x83, 0x0F, 0x04, @AG1, @CG3, @DG4
Datagrame émis par GW1 et reçu par GW2 : SOURCE = @AH1
DEST = @FH2
OPTION = 0x83, 0x0F, 0x08, @BG1, @CG3, @DG4

Datagrame émis par GW2 et reçu par GW3 : SOURCE = @AH1


DEST = @FH2
OPTION = 0x83, 0x0F, 0x08, @BG1, @CG3, @DG4

Datagrame émis par GW3 et reçu par GW4 : SOURCE = @AH1


DEST = @FH2
OPTION = 0x83, 0x0F, 0x0C, @BG1, @DG3, @DG4
Datagrame émis par GW4 et reçu par GW5 : SOURCE = @AH1
DEST = @FH2
OPTION = 0x83, 0x0F, 0x10, @BG1, @DG3, @EG4
Datagrame émis par GW5 et reçu par HOST2 : SOURCE = @AH1
DEST = @FH2
OPTION = 0x83, 0x0F, 0x10, @BG1, @DG3, @EG4

HOST2 est maintenant prêt à retouner des datagrammes en utilisant éventuellement l'option LOOSE ROUTING avec la liste de
gateways intermédiaires @EG4, @DG3, @BG1.

F05-019

p157
6 - LE PROTOCOLE IP

NTway.com J Options IP (suite) :


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Q Option 4 (Enregistrement d'instants)

J Format : Variable

J Classe : 2 (Debug et mesure)

J Rôle : Cette option permet l'enregistrement des instants successifs de passage dans les
différentes Gateways traversées dans le réseau.

J Valeur : L'option est constituée d'un octet de type, d'un octet de longueur, d'un octet de pointeur,
d'un octet de flags et d'une liste de "cases vides" fournies par l'émetteur et destinées à recevoir les
instants de passage dans chaque GATEWAY.
La taille de chaque case dépend de l'octet "flag" dont les 4 bits de poids faible contiennent les
indications suivantes :
0 Enregistrer seulement les instants, (4 oct/case).
1 Enregistrer adresses INTERNET et instant, (8 oct/case).
2 RFU.
3 Enregistrer les instants pour les adresses spécifiées, (8 oct/case).

Les poids forts de l'octet de flag contiennent le nombre de passerelles qui n'ont pu enregistrer
leurs informations, faute de place (champ overflow).
Remarque : Cette option n'est pas copiée en cas de fragmentation (bit CF toujours à 0).

Q Les instants sont représentés en ms depuis minuit (Temps Universel).

p158
6 - LE PROTOCOLE IP

NTway.com Fonctionnement de l'option Enregistrement d'instants :


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

HOST HOST
1 2

@AH1 @FH2

réseau réseau réseau réseau réseau réseau


A B C D E F

Adresse IP @AG1 GW1 @BG1 @BG2 GW2 @CG2 @CG3 GW3 @DG3 @DG4 GW4 @EG4 @EG5 GW5 @FG5

Datagrame émis par HOST1 et reçu par GW1 : SOURCE = @AH1


DEST = @FH2
OPTION = 0x44, 0x10, 0x05, 0x00,0, 0, 0
Datagrame émis par GW1 et reçu par GW2 : SOURCE = @AH1
DEST = @FH2
OPTION = 0x44, 0x10, 0x09, 0x00,T1, 0, 0

Datagrame émis par GW2 et reçu par GW3 : SOURCE = @AH1


DEST = @FH2
OPTION = 0x44, 0x10, 0x0D, 0x00, T1, T2, 0

Datagrame émis par GW3 et reçu par GW4 : SOURCE = @AH1


DEST = @FH2
OPTION = 0x44, 0x10, 0x11, 0x00, T1, T2, T3
Datagrame émis par GW4 et reçu par GW5 : SOURCE = @AH1
DEST = @FH2
OPTION = 0x44, 0x10, 0x11, 0x10, T1, T2, T3
Datagrame émis par GW5 et reçu par HOST2 : SOURCE = @AH1
DEST = @FH2
OPTION = 0x44, 0x10, 0x11, 0x20, T1, T2, T3

F05-020

p159
6 - LE PROTOCOLE IP

NTway.com Fonctionnement de l'option Enregistrement d'instants avec adresses imposées :

Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

HOST HOST
1 2

@AH1 @FH2

réseau réseau réseau réseau réseau réseau


A B C D E F

Adresse IP @AG1 GW1 @BG1 @BG2 GW2 @CG2 @CG3 GW3 @DG3 @DG4 GW4 @EG4 @EG5 GW5 @FG5

Datagrame émis par HOST1 et reçu par GW1 : SOURCE = @AH1


DEST = @FH2
OPTION = 0x44, 0x0C, 0x05, 0x03,@BG2, 0
Datagrame émis par GW1 et reçu par GW2 : SOURCE = @AH1
DEST = @FH2
OPTION = 0x44, 0x0C, 0x05, 0x03,@BG2, 0

Datagrame émis par GW2 et reçu par GW3 : SOURCE = @AH1


DEST = @FH2
OPTION = 0x44, 0x0C, 0x0D, 0x03,@BG2, T2

Datagrame émis par GW3 et reçu par GW4 : SOURCE = @AH1


DEST = @FH2
OPTION = 0x44, 0x0C, 0x0D, 0x03,@BG2, T2
Datagrame émis par GW4 et reçu par GW5 : SOURCE = @AH1
DEST = @FH2
OPTION = 0x44, 0x0C, 0x0D, 0x03,@BG2, T2
Datagrame émis par GW5 et reçu par HOST2 : SOURCE = @AH1
DEST = @FH2
OPTION = 0x44, 0x0C, 0x0D, 0x03,@BG2, T2

F05-021

p160
6 - LE PROTOCOLE IP

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
J Options IP (suite) :

Q Option 7 (Enregistrement de route)

J Format : Variable

J Classe : 0 (contrôle)

J Rôle : Permet de fournir une liste de "cases vides" dans le champ option pour que les
gateways successives y enregistrent leurs adresses (de sortie) afin de permettre au destinataire de
connaître le chemin qui a été employé. Au cas où la liste fournie serait insuffisamment longue, les
dernières gateways n'enregistreraient pas leurs adresses, sans que cela soit considéré comme une
erreur.

J Valeur : Même format que l'option 3 (loose routing).


Remarque : Cette option n'est pas copiée en cas de fragmentation (bit CF toujours à 0).

p161
6 - LE PROTOCOLE IP

NTway.com Fonctionnement de l'option Enregistrement de route :


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

HOST HOST
1 2

@AH1 @FH2

réseau réseau réseau réseau réseau réseau


A B C D E F

Adresse IP @AG1 GW1 @BG1 @BG2 GW2 @CG2 @CG3 GW3 @DG3 @DG4 GW4 @EG4 @EG5 GW5 @FG5

Datagrame émis par HOST1 et reçu par GW1 : SOURCE = @AH1


DEST = @FH2
OPTION = 0x07, 0x0F, 0x04, 00000000, 00000000, 00000000
Datagrame émis par GW1 et reçu par GW2 : SOURCE = @AH1
DEST = @FH2
OPTION = 0x07, 0x0F, 0x08, @BG1, 00000000, 00000000

Datagrame émis par GW2 et reçu par GW3 : SOURCE = @AH1


DEST = @FH2
OPTION = 0x07, 0x0F, 0x0C, @BG1, @CG2, 00000000

Datagrame émis par GW3 et reçu par GW4 : SOURCE = @AH1


DEST = @FH2
OPTION = 0x07, 0x0F, 0x10, @BG1, @CG2, @DG3
Datagrame émis par GW4 et reçu par GW5 : SOURCE = @AH1
DEST = @FH2
OPTION = 0x07, 0x0F, 0x10, @BG1, @CG2, @DG3
Datagrame émis par GW5 et reçu par HOST2 : SOURCE = @AH1
DEST = @FH2
OPTION = 0x07, 0x0F, 0x10, @BG1, @CG2, @DG3

HOST2 est maintenant prêt à retouner des datagrammes en utilisant éventuellement l'option LOOSE ROUTING avec la liste de
gateways intermédiaires @DG3, @CG2 , @BG1.

F05-022

p162
6 - LE PROTOCOLE IP

NTway.com J Options IP (suite) :


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Q Option 8 (Stream identifier) :

J Format : variable

J Classe : 0 (Contrôle)

J Rôle : Transporter un identifiant de Stream (pour les réseaux qui supportent le concept).

J Valeur : Identifiant sur 16 bits.


Remarque : Cette option doit être copiée en cas de fragmentation.

Q Option 9 (Routage impératif)

J Format : Variable

J Classe : 0 (contrôle)

J Rôle : Permet de mentionner une liste d'adresses IP de passerelles que l'on voir traverser
dans l'ordre où elles sont mentionnées. Le routage est dit "impératif" car chaque passerelle doit
impérativement atteindre la passerelle suivante directement, sans aucun intermédiaire.

J Valeur : Même format que l'option précédente (loose routing).


Remarque : Cette option est toujours copiée en cas de fragmentation (bit CF toujours à 1).

p163
6 - LE PROTOCOLE IP

IP sur X25 :
NTway.com J

Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Q Lorsqu'on possède des machines IP distantes, on peut pour les relier, soit utiliser une
liaison spécialisée, soit profiter d'un réseau X25 qui existe déjà. Dans ce deuxième cas, on
a besoin d'encapsuler IP sur X25.

ENCAPSULATION DE IP SUR X25

Dans la réalité de l'implémentation, X25 est vu par IP comme une


couche 2 : les NPDU IP sont encapsulés dans des paquets X25
( tunnelling ).

IP IP

X25 X25
HDLC Réseau X25 HDLC
Eth 1 1 Eth

Cette "couche 2 X25" ne pose jamais de problème de MTU,


X25 segmente et réassemble.

Deux RFC décrivent l'implémentation de IP sur X25 :

- Le RFC 877, "couche 2" monoprotocole, point à point ou multipoint.

- Le RFC 1356, "couche 2" multiprotocole, point à point ou multipoint,


avec deux possibilités pour le multiprotocole :
- utilisation du SNAP
- mettre l'identifiant du protocole dans le champ user data du
paquet d'appel X25.

F05-087A

p164
3 - LES COUCHES 1 ET 2 DANS L'ARCHITECTURE TCP-IP
LE CAS PARTICULIER DES WAN

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Réseau local IP et Backbone X25

LAN IP LAN IP

Application Application

Routeur
couche 4 Routeur couche 4

couche 3 IP couche 3 IP Nuage X25 couche 3 IP couche 3 IP

couche couche
couche 2 X25 X25 couche 2
2 2

Deux visions architecturales du réseau X25 par IP

On a une adresse IP par attachement On a une adresse IP par Circuit Virtuel


Vision LAN Vision LS

CV vu
@IP 192.93.10.4 @IP 192.93.10.5 @IP 192.93.11.0/24 @IP 192.93.14.0/24 comme LS
@IP 192.93.12.0/24 @IP 192.93.15.0/24
@IP 192.93.10.6
@IP 192.93.13.0/24 @IP 192.93.16.0/24

CV x
Nuage X25
Nuage X25

@IP 192.93.10.0/24 @IP 192.93.7.0/24


@IP 192.93.10.3 @IP 192.93.10.2 @IP 192.93.9.0/24 @IP 192.93.6.0/24
@IP 192.93.8.0/24 @IP 192.93.5.0/24

Dans ces deux visons on a une table statique dans les routeurs
faisant la correspondance entre les adresses X25 et les adresses IP .

ATTENTION : on a la possibilité d'établir autant de CV dans l'une ou l'autre des visions.

p165
6 - LE PROTOCOLE IP

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
ENCAPSULATION DE IP SUR X25 ( suite )

Point à point : chaque circuit virtuel entre deux machines TCP-IP


est vu comme une liaison spécialisée.

TCP
1.2 2.2 IP 3.2 4.2

X25

1.1 2.1 3.1 4.1


IP IP IP IP
TCP TCP TCP TCP

Remarques

Autant d'interfaces que de couples de machines à raccorder sont


configurées, d'où l'inflation de consommation des adresses IP.

F05-087B

p166
6 - LE PROTOCOLE IP

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

ENCAPSULATION DE IP SUR X25 (suite )

Multipoint : le réseau X25 est vu comme un LAN.

TCP
1.1 IP

X25

1.2 1.3 1.4 1.5


IP IP IP IP
TCP TCP TCP TCP

Remarques
La vision LAN est plus naturelle et moins consommatrice
d'adresses IP.

F05-087C

p167
6 - LE PROTOCOLE IP

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

ENCAPSULATION DE IP SUR X25 (suite)

Le RFC 877 est monoprotocole : un circuit virtuel ne peut supporter


qu'un protocole utilisateur de X25. Il est impossible de faire du
multiprotocole, même avec plusieurs cv car il n'existe pas
d'identifiant de protocole.
IP IPX Comment identifier
?? mon protocole
utilisateur ?
X25 cv cv

2
Le numéro de voie logique est un identifiant relatif et changeant
à chaque nouvelle connexion de niveau 3.

Le RFC 1356 est multiprotocole, par deux méthodes :


utilisation du SNAP identifiant du protocole dans
le champ user data d'X25
ARP ? IP IPX ...
IP IPX

SNAP
X25 cv cv

cv 2

Conclusion
Le RFC 877 n'est pas intéressant pour les architectures multiprotocoles,
il est souvent implémenté sur les hosts et les routeurs.
Le RFC 1356 est plus évolutif, on le trouve souvent sur les routeurs,
plus rarement sur les hosts.
F05-087D

p168
NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

-7-
LE PROTOCOLE ICMP
INTERNET Control Message Protocol)

p169
7 - LE PROTOCOLE ICMP

NTway.com J OBJECTIFS DU PROTOCOLE


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Q Le protocole ICMP est un protocole administratif permettant à des équipements


(essentiellement Gateway, mais dans certains cas Hosts) de gérer différents services de
réseau ou d'informer un émetteur de datagramme IP de problèmes rencontrés.

Q Ce protocole utilise IP comme outil de niveau 3 et se situe donc en fait au niveau 4. Les
implémentations de ICMP ne peuvent néanmoins pas être complètement indépendantes de
IP puisque la plupart des phénomènes rencontrés à l'origine des articles ICMP spontanés
sont en fait détectés par IP.

J ELEMENTS PROTOCOLAIRES

J Gestion d'écho (deux messages).

Q Rôle : La gestion d'écho permet à un émetteur d'envoyer une chaîne de caractères à un


destinataire (host ou gateway) et de recevoir cette chaîne en retour.
L'objectif est de tester l'accessibilité de l'équipement visé. L'utilisation de cette
fonctionnalité successivement sur tous les intermédiaires d'un chemin donné permet de
détecter aisément la localisation d'une défaillance de réseau.
Cette fonction est accessible sous la plupart des OS UNIX :
/etc/ping [-r] [-v] host [taille_msg [nb_msg] ]

p170
7 - LE PROTOCOLE ICMP

NTway.com J Gestion d'écho (deux messages).


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Q Message ICMP_ECHO_REQ (Id, Seq, Datas) :


Ce message est celui envoyé par l'utilisateur de la fonction écho. Id et Seq sont deux
champs à la disposition de l'émetteur pour corréler requêtes et réponses. Datas est le
message lui-même, de taille variable éventuellement nulle.

Q Message ICMP_ECHO_RESP (Id, Seq, Datas) :


Message de réponse.

Codage ICMP_ECHO_REQ (type = 0x08) et ICMP_ECHO_RESP (type = 0x00) :


(chaque division représentant un bit)

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

Type Checksum (idem IP)


0 0 0 0 0 0 0 0

Identifieur Séquence

Champ Data (optionnel) dont on attend l'écho

F05-023

p171
7 - LE PROTOCOLE ICMP

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Exemples de requêtes :

ICMP_ECHO_REQ ICMP_ECHO_RESP

08 00 B4 12 12 14 00 00 00 00 BC 12 12 14 00 00
85 53 5D 27 61 5B 03 00 85 53 5D 27 61 5B 03 00
08 09 0A 0B 0C 0D 0E 0F 08 09 0A 0B 0C 0D 0E 0F
10 11 12 13 14 15 16 17 10 11 12 13 14 15 16 17
18 19 1A 1B 1C 1D 1E 1F 18 19 1A 1B 1C 1D 1E 1F
20 21 22 23 24 25 26 27 20 21 22 23 24 25 26 27
28 29 2A 2B 2C 2D 2E 2F 28 29 2A 2B 2C 2D 2E 2F
30 31 32 33 34 35 36 37 30 31 32 33 34 35 36 37
F05-024

p172
7 - LE PROTOCOLE ICMP

Rapports d'erreur (1 message).


NTway.com J

Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Q Rôle : Rendre compte à l'émetteur d'un datagramme que celui-ci n'a pu être remis au
destinataire. Naturellement, ces messages ne sont pas utilisés en cas de non remise d'un
message ICMP à son destinataire!.

Q Message ICMP_UNREACHABLE_DEST (code, datagramme_détruit) :

J Le code permet de distinguer les raisons de destruction :


0 Réseau inaccessible.
1 Host inaccessible.
2 Protocole inaccessible.
3 Port inaccessible.
4 Fragmentation nécessaire, mais interdite.
5 Echec du Source Routing.
Le message ICMP contient également l'entête et les 8 premiers octets du datagramme IP détruit.

Codage ICMP_UNREACHABLE_DEST (type = 0x03) :


(chaque division représentant un bit)

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

Type Code Checksum (idem IP)

Inutilisé

En-tête IP et 8 premiers octets du datagramme rejeté

F05-025

p173
7 - LE PROTOCOLE ICMP

Contrôle de flux (1 message).


NTway.com J

Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Q Rôle : Permet à une passerelle (ou à un host) de signifier à un émetteur une congestion du
réseau et de solliciter un ralentissement des émissions. Aucun contrôle n'est fait pour
s'assurer que la source ralentit effectivement.
De même, aucun message n'existe pour dire à la source qu'elle peut repartir.
Une bonne implémentation de IP ralentit violemment ses émissions dès la réception d'un
tel message pendant quelques secondes, puis reprend progressivement son régime
normal en contrôlant le retour éventuel de messages de congestion.

Q Message ICMP_SOURCE_QUENCH (datagramme_détruit)


Contient l'entête du datagramme ayant fait "déborder la coupe".

Codage ICMP_SOURCE_QUENCH (type = 0x04) :


(chaque division représentant un bit)

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

Type Checksum (idem IP)


0 0 0 0 0 0 0 0

Inutilisé

En-tête IP et 8 premiers octets du datagramme rejeté

F05-026

p174
7 - LE PROTOCOLE ICMP

Redirection (1 message):
NTway.com J

Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Q Rôle : Permet à une passerelle de signifier à un Host l'existence d'une passerelle plus
opportune à utiliser. Ceci correspond en général au cas où deux passerelles existent sur
un même réseau et où un host de ce réseau dispose de tables de routages non à jour
l'enjoignant à utiliser la moins opportune des deux.
Ceci ne fonctionne pas entre deux passerelles.
L'émission de ce message oblige néanmoins la passerelle concernée à router le
datagramme concerné.

Q Message ICMP_REDIRECT (code, gateway_à_utiliser, datagramme_concerné)


Le code indique les éventuelles restrictions de reroutage :
0 rediriger pour le réseau demandé.
1 ne rediriger que pour le host demandé.
2 ne rediriger que pour le réseau et le TOS demandés.
3 ne rediriger que pour le host et le TOS demandés.
Codage ICMP_REDIRECT (type = 0x05) :
(chaque division représentant un bit)

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

Type Code Checksum (idem IP)

Adresse IP de la nouvelle passerelle à utiliser

En-tête IP et 8 premiers octets du datagramme mal routé

F05-027

p175
7 - LE PROTOCOLE ICMP

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

LE MESSAGE ICMP_REDIRECT :
LE BACK-UP DE LIEN

icmp_redirect
B A

i5

i4
i3
protocoles inter-routeurs
i1
i2

D C

i1 : datagramme routé par cet itinéraire selon le route add du host


i2 : cassure du lien entre deux routeurs
i3 : modification des tables de routage
i4 : le routeur s'aperçoit de l'incohérence du routage
i5 : le message icmp_redirect permet d'indiquer au host concerné
un routeur plus opportun à utiliser
F05-088A

p176
7 - LE PROTOCOLE ICMP

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

LE MESSAGE ICMP_REDIRECT :
RETABLISSEMENT DU LIEN

icmp_redirect
B A
i3

i2
protocoles inter-routeurs

i1

D C

i1 : rétablissement du lien
i2 : échange de tables de routages et calcul du chemin le plus
optimal ( modification des tables de routage )
i3 : le message icmp_redirect permet d'indiquer au host concerné
un routeur plus opportun à utiliser

F05-088B

p177
7 - LE PROTOCOLE ICMP

Time_out (1 message) :
NTway.com J

Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Q Rôle : Le message permet de signaler la mort de vieillesse d'un datagramme.

Q Message ICMP_TIME_OUT (code,entête_datagramme_détruit)


Code représente la raison de la destruction :

0 Champ TTL épuisé (probablement une boucle).


1 Attente trop longue lors du réassemblage de fragments

Codage ICMP_TIME_OUT (type = 0x0B) :


(chaque division représentant un bit)

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

Type Code Checksum (idem IP)

Inutilisé

En-tête IP et 8 premiers octets du datagramme détruit

F05-028

p178
7 - LE PROTOCOLE ICMP

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

LES MESSAGES ICMP_TIME_OUT ET


ICMP_UNREACHABLE_DEST

- datagramme trop vieux


- datagramme à détruire
(destination inconnue)
-> destruction et renvoi à
l'envoyeur de l'en-tête et
des 8 premiers octets.

retour à
l'envoyeur
ICMP

IP

2 2

1 1

Remarque
L'intérêt de récupérer l'information de la destruction du datagramme
est très faible.
- IP ne fait pas de rétention donc même s'il est prévenu de la
destruction, il ne saura pas répéter.
- La remise de l'information de destruction n'est pas garantie.

F05-105

p179
7 - LE PROTOCOLE ICMP

Erreur d'entête (1 message) :


NTway.com J

Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Q Rôle : Rendre compte de la détection d'une erreur rendant imposible l'exploitation d'un
datagramme. Les erreurs de checksum ne sont pas traitées de cette manière car dans de
tels cas, l'adresse IP de l'émetteur n'est même pas fiable. Il s'agit en général d'erreurs dans
les options.

Q Message ICMP_HEADER_ERROR (pointeur, entête_datagramme_détruit).


Le champ intéressant de ce message est le pointeur (octet) vers la partie du datagramme
détruit qui est considérée comme une anomalie.

Codage ICMP_HEADER_ERROR (type = 0x0C) :


(chaque division représentant un bit)

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

Type Checksum (idem IP)


0 0 0 0 0 0 0 0

Pointeur octet Inutilisé

En-tête IP et 8 premiers octets du datagramme détruit

F05-029

p180
7 - LE PROTOCOLE ICMP

Gestion des horloges (2 messages).


NTway.com J

Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Q Rôle : Le premier rôle de ces messages ICMP était de permettre le calcul des temps de
traversée dans le réseau, afin de détecter les éventuelles dégradations de performance de
ce réseau.
Une autre fonction a ensuite été adjointe, permettant également de calculer les différences
d'horloge entre les deux machines.

Q Mécanisme : Pour obtenir les résultats souhaités, 4 instants sont concernés :


T1 Instant d'émission du message aller.
T2 Instant de réception du message aller.
T3 Instant d'émission du message retour.
T4 Instant de réception du message retour.

En faisant l'hypothèse que les temps de transit sont les mêmes dans les deux sens, on
trouve : Temps_de_transit = (T4-T1-T3+T2)/2 et Delta_entre_horloges = (T2-
T1+T3-T4)/2

Q Hypothèse discutable, même si les messages aller et retour ont la même taille. Pour pallier
ce problème, la solution consiste à répéter les mesures et à moyenner les résultats.

p181
7 - LE PROTOCOLE ICMP

Gestion des horloges (2 messages).


NTway.com J

Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Q Ces formules montrent que seul l'émetteur peut faire les deux calculs, à condition que lui
soient transmis explicitement dans la réponse T2 et T3. De plus, afin d'éviter la
mémorisation de T1, puis à corréler question et réponse, il est opportun de passer
également T1 dans le requête et dans la réponse.

Q Message ICMP_CLOCK_REQ (Id, Seq,T1)


Id et Seq sont à la disposition de l'émetteur pour une corrélation éventuelle.

Q Message ICMP_CLOCK_RESP (Id, Seq, T1, T2, T3)

Codage ICMP_CLOCK_REQ (type = 0x0D) et ICMP_CLOCK_RESP (type = 0x0E) :


(chaque division représentant un bit)

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

Type Checksum (idem IP)


0 0 0 0 0 0 0 0

Identificateur Numéro de séquence

T1

T2
Champ présent, mais à 0 dans ICMP_CLOCK_REQ

T3
Champ présent, mais à 0 dans ICMP_CLOCK_REQ

F05-030

p182
7 - LE PROTOCOLE ICMP

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
LES MESSAGES ICMP_CLOCK_REQ ET
ICMP_CLOCK_RESP

But : calculer le temps de propagation entre deux couches IP dont les


systèmes ne sont pas forcément synchronisés.

ICMP ICMP
IP IP

T1 T1

T2
2 Tp = T4 - T1 - ( T3 - T2 )

Tp = ( T4 - T1 -T3 + T2 ) / 2 T3

T4 T1, T2, T3

Exemple
T1 = 8h, T2 = 9h10, T3 = 9h20, T4 = 8h30

On trouve Tp = 10 min.

F05-088C

p183
NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

-8-
L'ADRESSAGE DE NIVEAU 4

p184
8 - L'ADRESSAGE DE NIVEAU 4

NTway.com
Tél: 0-22-22-50-98 ADRESSAGE OSI
E-mail: ntway@iam.net.ma

7 plusieurs flux applicatifs


sur une même machine

PSAP id = SSAP id + PSEL


(dans l'univers)
6 PSEL PSEL PSEL PSEL identifie localement
l'utilisateur de la couche 6
SSAP id = TSAP id + SSEL
(dans l'univers)
5 SSEL identifie l'utilisateur
SSEL de la couche 5 c'est un
SSEL identificateur local relatif
au système
TSAP id = NSAP id + TSEL
identifie dans l'univers
4 Numéros de
l'utilisateur de la couche 4
TSEL
référence
TSEL TSEL identifie localement
l'utilisateur de la couche 4

NSAP id non corrélé géogra-


3 phiquement, unique dans
l'univers, qui adresse une
CLNP machine

LLSAP id GAA ou LAA


LLC
MAC SAP id unique dans le
MAC réseau local logique (LAA
ou GAA)

F05-061A

p185
8 - L'ADRESSAGE DE NIVEAU 4

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

ADRESSAGE OSI : adressage hiérarchique

ILLUSTRATION DU MULTIPLEXAGE

plusieurs flux applicatifs


sur une même machine

PSAP id = SSAP id + PSEL


6 PSEL PSEL PSEL PSEL identifie localement
l'utilisateur de la couche 6

SSAP id = TSAP id + SSEL

5 SSEL identifie l'utilisateur


SSEL de la couche 5 c'est un
SSEL identificateur local relatif
au système
TSAP id = NSAP id + TSEL
identifie dans l'univers
4 l'utilisateur de la couche 4
Numéros de
TSEL référence TSEL TSEL identifie localement
l'utilisateur de la couche 4

NSAP id non corrélé géogra-


3 phiquement, unique dans
voies logiques l'univers, qui adresse une
mode connecté machine

LLSAP id GAA ou LAA


LLC2
MAC SAP id unique dans le
MAC réseau local logique (LAA
ou GAA)
F05-061B

p186
8 - L'ADRESSAGE DE NIVEAU 4

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma ADRESSAGE TCP-IP

Processus
applicatifs

Adresse IP + n° de
port + type de
protocole = socket
La paire de sockets ex: (X, x, TCP)
identifie une 4
connexion de la sélection de
niveau 4 numéro de port l'utilisateur de la
x couche 4 se fait
par un identifiant
connexions TCP local, relatif au
système : le port.

X l'adresse IP doit
être unique dans
3 IP l'univers. Elle est
corrélée
géographiquement
(IAB, NIC ou INRIA)

LLC
MAC SAP id
Ethernet doit être
MAC unique dans un
réseau local
logique.
L'unicité de l'adresse MAC, en Ethernet DIX est garantie
au niveau mondial mais ce n'est q'un détail de gestion. F05-062

p187
8 - L'ADRESSAGE DE NIVEAU 4

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

LES DEFAUTS DE L'ADRESSAGE TCP-IP

deux occurences d'un même flux applicatif

socket socket

TCP TCP
x port ( X, x, TCP, Y, y ) y port
X ( X, x, TCP, Y, y )
Y
IP IP

1 1

Remarque
On a le même identifiant pour les deux connexions de transport.
C'est le développeur de l'application qui doit gérer le problème.
La solution mise en oeuvre sera d'utiliser un port de libre chez
l'appelant ou chez l'appelé.
F05-066

p188
8 - L'ADRESSAGE DE NIVEAU 4

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

ILLUSTRATION DU PROXY FTP

Le PROXY FTP est la capacité d'un tiers à déclencher un transfert de


fichiers entre deux machines distantes.

transfert de fichiers

FTP 1944 FTP


20
21 21

passif
actif port libre 1944

1944 1936
FTP maître
2012

Remarques

Ceci explique pourquoi l'application FTP a besoin des deux ports


20 et 21.

F05-081

p189
8 - L'ADRESSAGE DE NIVEAU 4

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

LA SOLUTION MISE EN OEUVRE PAR FTP

FTP FTP

TCP 1943 1821 TCP


1815 1830 (X, 1821, TCP, Y, 21) 20 21
(X, 1943, TCP, Y, 20)

(X, 1815, TCP, Y, 21)


(X, 1830, TCP, Y, 20)

IP X IP Y

Remarque

Première connexion vers port 21 : négociation du transfert.


Deuxième connexion du port 20 : transfert de données.
Il n'y a pas d'ambiguité entre les identifiants de connexions.
(paire de socket)

F05-067

p190
8 - L'ADRESSAGE DE NIVEAU 4

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
LA SOLUTION MISE EN OEUVRE PAR TELNET

Appelant Appelé

TCP 1951 1815 TCP


23

IP X IP Y

Remarque

Telnet est une application qui permet de déporter un terminal à


distance.
Le Telnet appelant se connecte toujours sur le port 23 du Telnet
appelé.
Le port 23 de l'appelé est multiconnexions.

F05-073

p191
8 - L'ADRESSAGE DE NIVEAU 4

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
UN EXEMPLE DE GESTION D'ADRESSAGE AU NIVEAU 4 UDP :
LES RPC DE SUN

XDR
RPC je veux le RPC toto RPC RPC
CLIENT le port correspondant SERVEUR TOTO
est 1888
UDP 1943 1821 UDP
1888 111

IP X IP Y

Remarque

A partir d'un port libre (ici 1821) le client appelle le serveur de


ports sur le port 111 (well known) et lui demande le numéro de port
correspondant au service désiré (ici 1888).
Puis le client s'active un deuxième port libre (ici 1943) pour appeler
le service toto dont il connaît maintenant le port.
Le fait que le client s'active sur un deuxième port libre n'est q'un
détail.
Le RPC serveur est parfois appelé port mapper.

F05-072

p192
NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

-9-
LE PROTOCOLE UDP

p193
9 - LE PROTOCOLE UDP
User Datagramm Protocol
NTway.com J OBJECTIFS
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Q Le protocole UDP est un protocole de transport en mode non connecté. Alors que IP met
en relation des hosts, au travers de passerelles, UDP met en relation des process qui n'ont
pas besoin de service de transport évolué.

Q Ses principales caractéristiques sont :

J fonctionnement en mode non connecté;

J pas de segmentation, pas de reséquencement des données;

J full-duplex (quoique la notion soit discutable dans un mode non connecté);

J détection d'erreurs éventuelle (mais pas de récupération);

J pas de contrôle de flux de bout en bout, évidemment;

p194
9 - LE PROTOCOLE UDP
User Datagramm Protocol
NTway.com J ELEMENTS PROTOCOLAIRES
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Q Un seul élément protocolaire existe dans UDP : le datagramme UDP ( UDP_DATA )

Q Chaque process impliqué dans un échange UDP est identifié localement par un numéro dit
"port". L'identification d'un process par un port pose un problème :

Q Il faut en effet permettre à l'appelant de connaître le port# de son correspondant. Ceci peut
se faire de trois façons :

J l'une consistant à se mettre d'accord de façon extérieure : peu pratique et sans garantie d'initiative.

J l'autre consistant à mettre en place un serveur de ports# qui pourrait faire des associations entre
noms de services et numéros de ports.
Q SUN Network Information Services, par exemple (nouveau nom d'un produit connu

précédemment sous la terminologie YELLOW PAGES, qu'il est désormais interdit d'employer,
car il s'agit d'une marque déposé de BRITISH TELECOM).

J la dernière, enfin, consistant à imposer un certain nombre de numéros de ports dits "well known
ports" pour des process réservés.

Q Voir le fichier /etc/services.

p195
9 - LE PROTOCOLE UDP
User Datagramm Protocol
NTway.com J ELEMENTS PROTOCOALIRES
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Affectation des principaux "wel_known_ports" UDP :


(extraits d'un fichier /etc/services)

echo 7/udp
discard 9/udp sink null
daytime 13/udp
chargen 19/udp ttytst source
time 37/udp timserver
name 42/udp nameserver
domain 53/udp
tftp 69/udp
sunrpc 111/udp
snmp 161/udp
snmp traps 162/udp
#
# UNIX specific services : these are NOT officially assigned
#
biff 512/udp comsat
who 513/udp whod
syslog 514/udp
talk 517/udp
route 520/udp router routed
F05-033

p196
9 - LE PROTOCOLE UDP
User Datagramm Protocol
NTway.com J Codage des datagrammes UDP
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Format des messages UDP


(chaque division représentant un bit)

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

Source port # Dest port#

Longueur Checksum

Champ Data (séquence d'octets de niveau supérieur)

F05-034

p197
9 - LE PROTOCOLE UDP
User Datagramm Protocol
NTway.com J Analyse des différents champs :
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Q Champ Source port :

J Taille: 16 bits.

J Abréviation : SRC PORT

J Valeur : PORT# de l'émetteur.

Q Champ Dest port :

J Taille : 16 bits.

J Abréviation : DEST PORT

J Valeur : PORT# du destinataire.

Q Champ Longueur :

J Taille : 16 bits.

J Abréviation : Néant.

J Valeur : 8 à ...; Ce champ donne la longueur complète du datagramme UDP (entête et données).

p198
9 - LE PROTOCOLE UDP
User Datagramm Protocol
NTway.com Q Champ Checksum :
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

J Taille : 16 bits.

J Abréviation : Néant.

J Valeur : Le checksum considéré concerne le datagramme UDP complet (entête et données), ainsi
qu'un pseudo entête rajouté pour le calcul du checksum et composé d'informations relevant de IP :

Adresse INTERNET de l'émetteur (32 bits);


Adresse INTERNET du destinataire (32 bits);
Octet PROT de l'entête IP (8 bits cadrés à droite sur 16 bits)
Longeur totale du datagramme UDP (16 bits);

Le calcul est fait comme pour IP en tenant compte d'un champ CHECKSUM initial de 0x0000 et en
additionnant les mots de 16 bits du segment et du pseudo entête (96 bits) un à un modulo 65535. Le
checksum est alors le complément à un (ou l'inverse) de la somme ainsi trouvée.
Cette méthode permet de contrôler le checksum en faisant d'un seul coup la somme modulo 65535
de tous les mots concernés et de vérifier qu'elle donne 0xFFFF (ou 0x0000).

Attention : Ce champ est en fait optionnel et la valeur 0x0000 dans le champ Checksum signifie que
celui ci n'a pas été calculé et ne doit en conséquence pas être vérifié.

J L'existence de deux valeurs 0 permet de ne pas confondre un champ checksum non calculé
(0x0000) et un champ checksum dont la valeur est nulle (0xFFFF).

p199
NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

- 10 -
LE PROTOCOLE TCP

p200
10 - LE PROTOCOLE TCP
Transmission Control Protocol
NTway.com J OBJECTIFS
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Q Le protocole TCP est l'absolu équivalent d'un protocole de transport ISO classe 4 (ISO
TP4). Il est évidemment rendu nécessaire par la faiblesse du service à datagramme de IP. Il
a donc pour rôle principal d'assurer une transmission fiable des données. Il résout tous les
problèmes de transmission non résolus par les couches inférieures (perte, duplication,
déséquencement...).

Q Ses principales caractéristiques sont :

J fonctionnement en mode connecté;

J protocole de transport orienté octet;

Q TCP a été construit pour offrir un service connecté à son utilisateur lui faisant apparaître
une connexion comme un flot FIFO bidirectionnel d'octets parfait, ne perdant pas
d'informations, et préservant la séquence des octets. Il ne permet donc pas à son
utilisateur de transmettre des blocs de données, mais seulement un flot linéaire continu
d'octets sans structure. Aucun mécanisme séparateur n'est d'ailleurs fourni.

Q Cette approche est inspirée du système d'exploitation UNIX où les fichiers et les lignes de
terminaux asynchrones apparaîssent aussi comme un flot linéaire continu d'octets sans
structure.

p201
10 - LE PROTOCOLE TCP
Transmission Control Protocol
NTway.com J OBJECTIFS
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Q L'utilisateur ne peut donc pas imposer à TCP de délimiter les blocs qu'il émet avec les
mêmes séparations que les blocs écrits par l'utilisateur à l'extrémité de la connexion TCP.

Q L'utilisateur distant reçoit un flot linéaire d'octets dans lequel il devra rechercher les
éventuels séparateurs de blocs fournis par l'utilisateur émetteur.

J segmentation, reséquencement des données;

J full-duplex;

J détection d'erreurs;

J contrôle de flux de bout en bout;

J simplicité de configuration par absence quasi totale de paramétrage et promotion de l'auto-


adaptation des paramètres significatifs.

p202
10 - LE PROTOCOLE TCP
Transmission Control Protocol
NTway.com J ELEMENTS PROTOCOLAIRES
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Connexion.

Q Le mécanisme de connexion s'effectue en trois temps

Connexion TCP :

TCP_SEG_SYN

TCP_SEG_SYN_ACK

TCP_SEG_ACK

F05-035

Q La connexion permet l'échange et/ou la négociation d'un grand nombre de paramètres

p203
10 - LE PROTOCOLE TCP
Transmission Control Protocol
NTway.com J ELEMENTS PROTOCOLAIRES
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
La notion de port.

Q Alors que IP est un mécanisme de communication inter-hosts, TCP est un mécanisme de


communication inter process. Chaque process est identifié localement par un numéro dit
"port". Plusieurs connexions peuvent être établies sur le même port sur une machine
donnée, mais il est impossible d'avoir deux connexions TCP sur le même couple de ports.

Q En fait, l'unicité exigée concerne le quintuplé (SOURCE @IP, SOURCE PORT, DEST @IP,
DEST PORT, PROTOCOL).

Q L'identification d'un process par un port pose deux problèmes :

Q D'une part, il faut permettre à l'appelant de connaître le port# de son correspondant. Ceci
peut se faire de trois façons :

J l'une consistant à se mettre d'accord de façon extérieure : peu pratique et sans garantie d'initiative.

J l'autre consistant à mettre en place un serveur de ports# qui pourrait faire des associations entre
noms de services et numéros de ports.
Q SUN Network Information Services, par exemple.

J la dernière, enfin, consistant à imposer un certain nombre de numéros de ports dits "well known
ports" pour des process réservés.

Q Voir le fichier /etc/services.

p204
10 - LE PROTOCOLE TCP
Transmission Control Protocol
NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

MODELE OSI : LE GEL DE REFERENCE

Application Application

4 4

deuxième
connexion

Mode non connecté

numéros de référence

Remarque

Si la connexion de niveau 4 est cassée à cause d'un problème de


niveau 3, le numéro de référence est gelé un certain temps et le
système s'en choisit un autre pour une deuxième connexion. Cela
ne pose aucun problème, car en OSI, le numéro de référence sert à
identifier une connexion de niveau 4.
Le même phénomène n'est pas possible en TCP/IP : on n'a pas
d'identifiant unique de connexion!

F05-108

p205
10 - LE PROTOCOLE TCP
Transmission Control Protocol
NTway.com Affectation des principaux "well_known_ports" TCP :
(extraits d'un fichier /etc/services)
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
echo 7/tcp
discard 9/tcp sink null
systat 11/tcp users
daytime 13/tcp
netstat 15/tcp
chargen 19/tcp ttytst source
ftp-data 20/tcp
ftp 21/tcp
telnet 23/tcp
smtp 25/tcp mail
time 37/tcp timserver
whois 43/tcp nicname # usually to sri-nic
domain 53/tcp
rje 77/tcp
finger 79/tcp
link 87/tcp ttylink
supdup 95/tcp
hostnames 101/tcp hostname # usually to sri-nic
iso-tsap 102/tcp
x400 103/tcp # ISO Mail
x400-snd 104/tcp
csnet-ns 105/tcp
pop-2 109/tcp # Post Office
sunrpc 111/tcp
uucp-path 117/tcp
nntp 119/tcp readnews # Network News Transfer
ntp 123/tcp # Network Time Protocol
NeWS 144/tcp news # Window System
#
# UNIX specific services : these are NOT officially assigned
#
exec 512/tcp
login 513/tcp
shell 514/tcp cmd # no passwords used F05-036

printer 515/tcp spooler # line printer spooler


courier 530/tcp rpc
uucp 540/tcp uucpd # uucp daemon
A noter : plusieurs process sont appelables via TCP et via UDP. Chaque fois que possible, dans un tel cas, les mêmes numéros
de ports sont employés, bien qu'aucune règle ne l'impose.

p206
10 - LE PROTOCOLE TCP
Transmission Control Protocol
NTway.com J ELEMENTS PROTOCOLAIRES
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Q Pour régler ce problème, les octets échangés sur une connexion seront numérotés de
façon séquentielle et le numéro de départ sera convenu entre les deux parties à
l'établissement de la connexion. Il sera non nul et normalement supérieur au dernier
numéro d'octet échangé au préalable. Ce numéro initial symbolise le "dernier octet
envoyé" et est acquitté par le numéro suivant (prochain octet attendu). Afin de se protéger
contre les arrêts et reprises à froid des systèmes (conduisant à oublier le dernier numéro
envoyé et à repartir à 0, avec tous les risques afférents), il est convenu que le numéro de
départ est calculé à partir de l'heure.

J En fait, il s'agit des 32 bits de poids faible d'une horloge (éventuellement fictive) dont le bit de droite
évolue toutes les 4 microsecondes, ce qui fait un tour complet en environ 4h45, largement au
dessus du délai moyen de survie dans le réseau!

p207
10 - LE PROTOCOLE TCP
Transmission Control Protocol
NTway.com J ELEMENTS PROTOCOLAIRES
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Connexion.

Connexion TCP :

TCP_SEG_SYN (SRC=P1, DEST=P2, SEQ=x)

TCP_SEG_SYN_ACK (SRC=P2, DEST=P1, SEQ=y, ACK=x+1)

TCP_SEG_ACK (SRC=P1, DEST=P2, SEQ=x+1, ACK=y+1)

Nota : En cas de collision de connexions, le TCP_SEG_ACK peut être inutile et la connexion se fait en fait en 4 temps
par double échange SYN, SYN+ACK)
F05-037

Q La connexion TCP peut de plus comporter des options (et notamment la négociation de la
taille des segments échangés).

p208
10 - LE PROTOCOLE TCP
Transmission Control Protocol
NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
La Déconnexion TCP.

Q La rupture de connexion peut se faire d'une façon normale (propre, "graceful") ou d'une
façon brusque ("abort").

Q La déconnexion normale se fait en quatre temps :

Déconnexion TCP normale :

TCP_SEG_FIN (SRC=P1, DEST=P2)

TCP_SEG_ACK (SRC=P2, DEST=P1)

Un sens est maintenant fermé, mais l'autre peut continuer à émettre ...

TCP_SEG_FIN (SRC=P2, DEST=P1)

TCP_SEG_ACK (SRC=P1, DEST=P2)

F05-038

Q A noter : L'indépendance des processus de déconnexion entre les deux sens


p209
10 - LE PROTOCOLE TCP
Transmission Control Protocol
NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
La Déconnexion TCP.

Q La procédure de déconnexion anormale se fait en un seul temps :

Déconnexion TCP anormale :

TCP_SEG_RST (SRC=P1, DEST=P2)

Aucune autre data n'est sensé passer sur la connexion celle-ci est cassée de
façon abrupte.

F05-039

Q Le RESET n'est normalement utilisé que lors de la détection d'une anomalie protocolaire,
ou pour refuser une connexion. Un RESET comprend également un numéro de séquence
dont la bonne valeur est vérifiée avant d'accepter la fermeture brutale.

J La valeur est dite bonne lorsqu'elle se situe à l'intérieur de la fenêtre courante. Des conventions
spéciales sont prévues pour traiter les RESET en cours de connexion (où les numéros de
séquences et les fenêtres n'ont pas été définis).

p210
10 - LE PROTOCOLE TCP
Transmission Control Protocol
NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Le transfert des données TCP.

Q Le transfert se fait simplement par émission de segments contenant des DATA. Les
données sont numérotées au niveau octet, et non au niveau bloc :

Transfert de données en TCP :

TCP_SEG_(SRC=P1, DEST=P2, SEQ=1000, LG=200)

TCP_SEG_(SRC=P1, DEST=P2, SEQ=1200, LG=100)

TCP_SEG_(SRC=P1, DEST=P2, SEQ=1300, LG=300)

...
F05-040

p211
10 - LE PROTOCOLE TCP
Transmission Control Protocol
NTway.com
Tél: 0-22-22-50-98 F05-084
E-mail: ntway@iam.net.ma
LE TRANSFERT DE DONNEES

Application Application

service TCP TCP service


protocole
1000
x 500

x+500 200 700


x+700 300
1000
x+1000 500
x+1500 200 1000
x+1700 300
300

OU 1000
x
x+200 100

200 300

x+300 700 700

TCP est gestionnaire de ses buffers.


TCP gère donc l'émission de ses segments en fonction :
- de ses buffers
- du contrôle de flux de sa couche homologue
- de la taille maximale des segments qu'il a le droit d'envoyer
Le concept de bloc n'existe pas.
Le respect de l'entité TCP-SDU ne peut être garanti.
Il n'y a pas de bit F dans TCP d'où le RFC 1006 pour les empilements
OSI sur TCP.

p212
10 - LE PROTOCOLE TCP
Transmission Control Protocol
NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

La détection de perte de données dans TCP.

Q IP étant par conception peu fiable, il est impératif que TCP sache détecter une perte
d'octets et sache la réparer. Cette détection de perte ne peut se faire par rejet en cas de
réception de données hors séquence, puisque le déséquencement n'est pas une erreur
sous IP. Pour traiter ces problèmes, TCP gère donc un mécanisme d'acquittement, un
timer de surveillance T1 et une technique de répétition. Naturellement, les acquittements
sont différés et groupés (un acquittement précis acquitte toutes les données antérieures à
la donnée acquittée explicitement) :

J Ce constat est le même que celui qui a conduit l'ISO à traiter des TPDU-RJ en classe 3, et à ne plus
les traiter en classe 4.

p213
10 - LE PROTOCOLE TCP
Transmission Control Protocol
NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Transfert de données en TCP et acquittements :

TCP_SEG ( SEQ=1000, LG=200)

TCP_SEG ( SEQ=1200, LG=100)

TCP_SEG_ACK( ACK=1300)

TCP_SEG ( SEQ=1300, LG=200)


...
TCP_SEG ( SEQ=1500, LG=200)

Timer T1

TCP_SEG ( SEQ=1300, LG=300)

TCP_SEG ( SEQ=1600, LG=300)

TCP_SEG_ACK( ACK=1900)

A noter : LE SEGMENT_OVERLAP parfaitement légal !!!


F05-041

p214
10 - LE PROTOCOLE TCP
Transmission Control Protocol
NTway.com Q Il est à remarquer que la stratégie de réémission sur time_out n'est pas imposée par le
Tél: 0-22-22-50-98 standard TCP (retransmission de tous les segments ou simplement du premier....). Toutes
E-mail: ntway@iam.net.ma
les stratégies fonctionnent mais leur efficacité dépend de la stratégie de contrôle des
récepteurs (acceptation ordonnée uniquement, ou acceptation quelconque), laquelle n'est
pas définie non plus par le standard. Il est donc compliqué de garantir a priori l'efficacité
d'une paire de TCP coopérants.

Q Le problème du choix du Timer T1.

Q Le choix de T1 n'est pratiquement jamais fourni statiquement dans la configuration de


TCP, et ceci pour deux raisons :

Q D'une part parce que IP et TCP se veulent des protocoles utilisables dans des contextes où
les utilisateurs n'ont pas forcément des compétences réseau avancées.

Q D'autre part parce que l'utilisation de IP avec routage adaptatif comme couche 3 peut
entraîner des modifications importantes des temps de traversées du réseau au cours de la
vie d'une connexion.

Q En conséquence, le paramètre T1 est en général calculé et adapté de façon dynamique. En


effet, imposer une valeur permanente fixe est peu réaliste car une valeur élevée rendra très
peu performant TCP si les pertes sont fréquentes, alors qu'une valeur trop faible de T1
créera un trafic supplémentaire inutile et coûteux.

p215
10 - LE PROTOCOLE TCP
Transmission Control Protocol
NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Q Il est à remarquer que la stratégie de réémission sur time_out n'est pas imposée par le
standard TCP (retransmission de tous les segments ou simplement du premier....). Toutes
les stratégies fonctionnent mais leur efficacité dépend de la stratégie de contrôle des
récepteurs (acceptation ordonnée uniquement, ou acceptation quelconque), laquelle n'est
pas définie non plus par le standard. Il est donc compliqué de garantir a priori l'efficacité
d'une paire de TCP coopérants.

Q Le calcul adaptatif est en général fondé sur la mesure permanente des temps
d'acquittements réels constatés et sur l'application d'une fonction de lissage afin de limiter
l'influence d'un temps d'acquittement ponctuel trop court ou trop grand :

J On calcule en général un temps d'acquittement moyen ACK_mean_delay par pondération :

Q Où _ représente un facteur d'autant plus grand que le réseau est stable (typiquement de
l'ordre de 0.8 à 0.9) et ß représente la marge de précaution admise (typiquement 1.4 à 2.0).

J ACK_mean_delay = *ACK_mean_delay + (1-)*last_ack_delay

J T1 = ß*ACK_mean_delay

p216
10 - LE PROTOCOLE TCP
Transmission Control Protocol
NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Q Cette méthode de calcul n'est malheureusement pas parfaite. En effet, si le temps de


traversée (et donc d'acquittement) croît brutalement et se stabilise à une valeur nettement
supérieure à ACK_mean_delay, il peut se produire une confusion dans la couche TCP
émettrice :

J Hypothèses de départ :
= 0.8
ß = 1.5
ACK_mean_delay = 2s (stable)
T1 = ß*2 = 3s.

J Evénement : Brusque montée et stabilisation du temps d'acquittement à 4s.

J Phénomène : Le segment suivant n'est pas acquitté dans le délai T1 (3s). L'émetteur le pense perdu
et le répète donc au bout de 3s. Au bout de 4s, l'acquittement survient et est interprété comme
l'acquittement de la répétition, ce qui met la valeur instantanée du temps d'acquittement à 1s.

J Le nouveau ACK_mean_delay devient 0.8*2 + 0.2*1 = 1.8


T1 descend donc à ß*1.8, soit 2.7s
L'acquittement réel de la répétition est reçu ultérieurement par TCP, avec respect, bonheur et
étonnement, mais ne change rien.

Le segment suivant n'est pas acquitté dans le délai T1 (2.7s). L'émetteur le pense perdu et le répète
donc au bout de 2.7s. Au bout de 4s, l'acquittement survient et est interprété comme l'acquittement
de la répétition, ce qui met la valeur instantanée du temps d'acquittement à 1.3s.

p217
10 - LE PROTOCOLE TCP
Transmission Control Protocol
NTway.com Le nouveau ACK_mean_delay devient 0.8*1.8 + 0.2*1.3 = 1.7
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma T1 descend donc à ß*1.7, soit 2.55s
L'acquittement réel de la répétition est reçu ultérieurement par TCP, mais ne change rien.

Le segment suivant n'est pas acquitté dans le délai T1 (2.55s). L'émetteur le pense perdu et le
répète donc au bout de 2.55s. Au bout de 4s, l'acquittement survient et est interprété comme
l'acquittement de la répétition, ce qui met la valeur instantanée du temps d'acquittement à 1.45s.

Le nouveau ACK_mean_delay devient 0.8*1.7 + 0.2*1.45 = 1.65


T1 descend donc à ß*1.65, soit 2.47s
L'acquittement réel de la répétition est reçu ultérieurement par TCP, mais ne change rien.

J Conclusion : Il est aisé de montrer que ce phénomène converge rapidement vers une valeur de T1
de 2.4s alors qu'il aurait fallu converger vers 6s.
J Ce phénomène est connu sous le nom de "Cypress syndrome", du nom du réseau US qui l'a mis en
évidence le premier.

J Solution : Exiger de la couche TCP qu'elle contrôle le ratio standard d'acquittements reçus par
datagramme envoyé. En cas d'anomalie, décider d'augmenter brutalement la valeur de
ACK_mean_delay, par exemple en la doublant (puisqu'on a deux acquittements par envoi) et laisser
le temps la stabiliser à sa bonne valeur. Ici, cela donnerait ACK_mean_delay à 3.2s et T1 à 4.8s. En
6 segments, T1 atteint 5.6s et en 20 il est stabilisé à 6s.

Q La conclusion est encore que la robustesse d'une couche TCP dépend grandement de
l'expérience du "designer" du logiciel, car les mécanismes que nous venons d'évoquer ne
sont malheureusement pas décrits dans le standard mais au travers des divers RFC/IEN.

p218
10 - LE PROTOCOLE TCP
Transmission Control Protocol
NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

ILLUSTRATION DU CYPRESS SYNDROM.

ALGORITHME DE CALCUL DE T1 :
New_ack_mean_delay = α * Ack_mean_delay+ (1-α)*dernière_mesure_de_ack
T1 = β * New_ack_mean_delay
Avec : 0 <= α <= 1
Si α = 0 le passé n'a pas de poids.
Si α = 1 le présent n'a pas de poids.

HYPOTHESES : α = 0.8 β = 1.5


Ack_mean_delay = 2s (stable)
T1 = β *2 = 3s

EVENEMENT : brusque montée et stabilisation du temps d'acquittement à 4s.

TCP TCP

T1 = 3s
données

Ack
dernière mesure = 1s données répétées

j'ai bien fait de répéter,


le système se porte mieux.
Illusion!

New_ack_mean_delay = 0.8 * 2 + 0.2 * 1 = 1.8 s

T1 = β * 1.8 = 2.7 s
F05-068A

p219
10 - LE PROTOCOLE TCP
Transmission Control Protocol
NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

ILLUSTRATION DU CYPRESS SYNDROM (suite)

Répétition de l'algorithme avec le nouveau T1


TCP TCP

T1 = 2.7 s
données

Ack
dernière mesure = 1.3s données répétées

Ack

New_ack_mean_delay = 0.8 * 1.8 + 0.2 * 1.3 = 1.7 s

T1 = β * 1.7 = 2.55 s

T1 converge ainsi vers 2.4 s

Conclusion : tout est répété deux fois.


Solution : multiplier T1 par le nombre de répétitions constatées.

Remarque : le fait de recevoir 2 ACK pour un segment de données n'est


pas symptomatique d'un problème.

F05-068B

p220
10 - LE PROTOCOLE TCP
Transmission Control Protocol
Le contrôle de flux dans TCP.
NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Q Le mécanisme de contrôle de flux dans TCP est comparable à celui disponible en OSI. Il
est fondé sur un droit à anticiper, fourni par le récepteur à l'émetteur, et limitant la légalité
des envois par celui-ci. Ce droit est appelé Window (fenêtre), est indépendant dans chaque
direction de celui de l'autre direction, et est échangé au cours de la connexion :

Transfert de données en TCP et pseudo contrôle de flux :

TCP_SEG_SYN ( SEQ=999)

TCP_SEG_SYN_ACK ( SEQ=4999, ACK=1000, WINDOW=300)

TCP_SEG_ACK (SEQ=1000, ACK=5000, WINDOW=500)

TCP_SEG ( SEQ=1000, LG=200)

TCP_SEG ( SEQ=1200, LG=100)

Attente d'acquittement car la limite de fenêtre est atteinte

TCP_SEG_ACK( ACK=1300)

TCP_SEG ( SEQ=1300, LG=100)

TCP_SEG ( SEQ=1400, LG=100)

TCP_SEG ( SEQ=1500, LG=100)

Attente à nouveau ...

F05-042

Q En réalité, le mécanisme présenté ci dessus n'est pas véritablement un contrôle de flux car
l'obligation d'acquitter dans les délais surveillés par T1 empêche d'arrêter le flux par le
seul biais du non acquittement.

p221
10 - LE PROTOCOLE TCP
Transmission Control Protocol
Pour que cela devienne réellement un contrôle de flux, il faut ajouter une fonctionnalité :
NTway.com Q

chaque TCP_SEG_ACK contient une nouvelle valeur de la fenêtre permettant ainsi, si on le


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma souhaite, un véritable arrêt :

Transfert de données en TCP et vrai contrôle de flux :

TCP_SEG_SYN ( SEQ=999)

TCP_SEG_SYN_ACK ( SEQ=4999, ACK=1000, WINDOW=300)

TCP_SEG_ACK (SEQ=1000, ACK=5000, WINDOW=500)

TCP_SEG ( SEQ=1000, LG=200)

TCP_SEG ( SEQ=1200, LG=100)

Attente d'acquittement car la limite de fenêtre est atteinte

TCP_SEG_ACK( ACK=1300, WINDOW=100)

TCP_SEG ( SEQ=1300, LG=100)

TCP_SEG_ACK ( SEQ=1400, WINDOW=0)

Le flux est maintenant arrêté légalement et ne reprendra qu'au prochain ACK non nul.

TCP_SEG_ACK ( SEQ=1400, WINDOW=500)

TCP_SEG ( SEQ=1400, LG=300)

F05-043

p222
10 - LE PROTOCOLE TCP
Transmission Control Protocol
NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Q Le numéro du dernier octet légal peut, si l'on n'y prend garde, diminuer d'un ACK à l'autre
(ACK = 1000, W = 1000 suivi de ACK = 1500, W = 200). Ce phénomène n'est pas interdit par
le standard, mais il reste fortement non recommandé. Un TCP émetteur détectant ce
phénomène doit être capable de le traiter, c'est à dire de considérer les éventuels octets
envoyés devenus illégaux (ici les octets 1700 à 1999) comme écartés par le destinataire, et
donc à répéter.

J Ce phénomène s'appelle "Window shrink".

Q D'autre part, le déséquencement possible des TCP_SEG_ACK peut rendre difficile


l'interprétation de la bonne valeur de la fenêtre. Une méthode consiste à reséquencer
(lorsque cela est possible) les ACK en fonction du numéro d'octet qu'ils acquittent. Ceci
n'est pas toujours possible, par exemple quand plusieurs ACK acquittent le même octet.

Q Enfin, un problème se pose lors d'une fenêtre fermée (W = 0) si l'acquittement de


réouverture est perdu par IP. Dans ce cas, le correspondant n'est pas informé et ne peut
donc pas repartir. Pour traiter ce problème, il est conseillé (mais non imposé) d'émettre
régulièrement des TCP_SEG_ACK de prudence. La fréquence suggérée est de 2 minutes

J Ce qui montre encore une fois la dépendance entre la robustesse d'une implémentation TCP et la
qualité / compétence / expérience de l'équipe de conception.

p223
10 - LE PROTOCOLE TCP
Transmission Control Protocol
NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

LA GENERATION DE TRAFIC

TCP TCP

TCP_SEG = 1000
lg = 1000

TCP_ACK = 2000
W = 1000

TCP_SEG = 2000
lg = 1000

TCP_ACK = 3000
W=0
T2
TCP_ACK = 3000
Interprétation abusive W = 1000
de shrink-window!
d'où blocage du
système TCP_ACK = 3000
W = 1000

Remarque

La génération de trafic évite de bloquer le protocole TCP suite à


une interprétation abusive de "shrink window".

F05-083A

p224
10 - LE PROTOCOLE TCP
Transmission Control Protocol
NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

LA GENERATION DE TRAFIC ( suite )

TCP TCP

TCP_SEG = 1000
lg = 1000

TCP_ACK = 2000
W = 1000

TCP_SEG = 2000
lg = 1000

TCP_ACK = 3000
W=0
T2
Perte de la réouverture TCP_ACK = 3000
de fenêtre! W = 1000
d'où blocage du
système TCP_ACK = 3000
W = 1000

Remarques
La génération de trafic évite de bloquer le protocole TCP suite à
une réouverture de fenêtre qui n'arrive pas.
Les timer T2 n'ont pas besoin d'être identiques des deux côtés.

F05-083B

p225
10 - LE PROTOCOLE TCP
Transmission Control Protocol
NTway.com La notion de "remise forcée".
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Q L'absence complète de notion de séparateur et de bloc fait que la décision de remise d'un
octet à l'utilisateur par le TCP récepteur est complètement indépendante de l'émetteur. En
particulier, rien n'empêche le récepteur de "bufferiser" certains octets jusqu'à remplissage
d'un certain pourcentage de ses ressources ou épuisement d'un timer local.

Q Afin de pouvoir contrôler partiellement ce phénomène, le TCP émetteur (sous contrôle de


son utilisateur) peut demander au récepteur la remise des données présentes dans son
segment.

Q Attention, le PUSH ne garantit pas la remise indépendante. En effet, un déséquencement


peut conduire le récepteur à avoir en même temps deux segments à remettre à l'utilisateur
avec la demande PUSH. Dans ce cas, une seule remise est parfaitement légale.

Q Il ne faut donc pas utiliser le mécanisme de PUSH comme notion de délimitation.

p226
10 - LE PROTOCOLE TCP
Transmission Control Protocol
NTway.com La notion de "remise forcée".
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Remise forcée des données :


(ce dessin ne contient pas la représentation des ACK, pour l'alléger)

TCP_SEG (SEQ=1000, LG=200)


Bufferisé ...

TCP_SEG (SEQ=1200, LG=100)


Remise à l'utilisateur
(décision locale)

TCP_SEG (SEQ=1300, LG=200)


Bufferisé

TCP_SEG (SEQ=1500, LG=100)


Bufferisé

TCP_SEG_PSH (SEQ=1600, LG=200)


Remise à l'utilisateur
(PUSH demandé)
TCP_SEG_PSH (SEQ=1800, LG=700)

Remise à l'utilisateur
(PUSH demandé)

... F05-044

p227
10 - LE PROTOCOLE TCP
Transmission Control Protocol
NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
TCP : LA NOTION DE REMISE FORCEE DE
DONNEES (PUSH)

Application Application

données "pushées"
*
TCP TCP

*
IP IP

MODE NON CONNECTE

Remarque

Quand TCP reçoit des données "pushées", il se dépêche d'envoyer


toutes les données en attente de l'autre côté.
De même, à la réception d'un octet "pushé", TCP récepteur remet
toutes ses données à l'application.

F05-107

p228
10 - LE PROTOCOLE TCP
Transmission Control Protocol
NTway.com La notion de données urgentes.
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Q Il est possible à un émetteur de signaler au récepteur que des données présentant un


caractère d'urgence sont en train d'être envoyées. Le standard ne spécifie pas la façon
dont le récepteur doit se comporter, mais il doit au moins remettre ces données à son
utilisateur en indiquant qu'elles sont urgentes (notion de "OUT_OF_BAND_DATAS"). Les
données urgentes peuvent parfaitement s'étendre au delà du segment courant. Pour ce
faire, le segment correspondant fournit l'indication du nombre d'octets de données
urgentes restant à envoyer (relativement au premier octet du segment) :

Mécanisme de données urgentes :


(ce dessin ne contient pas la représentation des ACK, pour l'alléger)

TCP_SEG (SEQ=1000, LG=200)


Bufferisé ...
et passage en MODE URGENT

TCP_SEG (SEQ=1200, LG=100)


Bufferisé ...

TCP_SEG (SEQ=1300, LG=200)


Remise à l'utilisateur

...
des 800 octets urgents
(dont 200 de ce segment)
puis
sortie du MODE URGENT
et remise éventuelle des
200 autres octets.
F05-045

p229
10 - LE PROTOCOLE TCP
Transmission Control Protocol
NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

TCP : LA NOTION DE DONNEES URGENTES


OOB (Out Of Band)

Application Application

données urgentes

TCP TCP

IP IP

MODE NON CONNECTE

Remarque

Les données urgentes ne sont pas soumises au contrôle de flux


vertical, mais cependant soumises au contrôle de flux horizontal :
si TCP n'a pas le droit d'envoyer de données (Window nulle), les
données urgentes ne passeront pas car elles sont concaténées
à un segment de données.

F05-106

p230
10 - LE PROTOCOLE TCP
Transmission Control Protocol
NTway.com J CODAGE DES SEGMENTS TCP
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Représentation.

Q Tous les segments TCP ont le même format. La distinction entre les différents types
(SEG_SYN, SEG_SYN_ACK, SEG_RST, ...) se fait par la présence de bits particuliers dans
le quatorzième octet de l'en-tête.

Format des segments TCP


( chaque division représentant un bit )

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

Source port # Dest port#

Numéro de séquence ( SEQ )

Numéro d'acquittement (ACK )

Taille de RFU U A P R S F
l'entête R C S S Y I Window
G K H T N N
Position relative
Checksum
des dernières données urgentes

Champ Options
[ Padding ]

Champ Data ( séquence d'octets du niveau supérieur )

F05-046

p231
10 - LE PROTOCOLE TCP
Transmission Control Protocol
NTway.com J ANALYSE DES DIFFERENTS CHAMPS
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Q Champ Source port :
J Taille : 16 bits.

J Abréviation : SRC PORT.

J Valeur : PORT# de l'émetteur

Q Champ Dest port :

J Taille : 16 bits.

J Abréviation : DEST PORT.

J Valeur : PORT# du destinataire.

Q Champ Numéro de séquence :


J Taille : 32 bits.

J Abréviation : SEQ.

J Valeur : Numéro de séquence du premier octet de données de ce segment. Dans le cas d'un
TCP_SEG_SYN, ce champ contient l'indication du dernier octet que l'on est supposé avoir envoyé.
Au cours de la connexion, ce champ est normalement calculé d'après l'horloge.
J Ceci peut être compris comme si le TCP_SEG_SYN envoyait un octet de données fictif.

p232
10 - LE PROTOCOLE TCP
Transmission Control Protocol
NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Q Champ Numéro d'acquittement :

J Taille : 32 bits.

J Abréviation : ACK.

J Valeur : Numéro du prochain octet attendu. Ce numéro constitue donc un acquittement de tous les
octets de numéros strictement inférieurs.

Q Champ Header Length :

J Taille : 4 bits.

J Abréviation : IHL

J Valeur : longueur de l'entête TCP (y compris la partie options) exprimée en mots de 32 bits.

La valeur minimale de ce champ est 5.


La valeur maximale est 15, ce qui limite la taille du champ options à 10 mots, soit 40 octets.

Ce champ permet de déterminer la position relative des données dans le segment.

p233
10 - LE PROTOCOLE TCP
Transmission Control Protocol
NTway.com Q Bits de "type de segment" :
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
J Taille : 6 bits.

J Abréviation : spécifique à chaque bit.

J Valeur :
URG Valide le champ URGENT_PTR.
(voir TCP_SEG_URG ci dessus)
ACK Valide le champ ACK
(voir TCP_SEG_ACK ci dessus)
PSH Demande la remise forcée des données
(voir TCP_SEG_PSH ci dessus)
RST Demande la rupture anormale de la connexion
(voir TCP_SEG_RST ci dessus)
SYN Demande l'établissement de la connexion
(voir TCP_SEG_SYN ci dessus)
FIN Demande la fin de la connexion
(voir TCP_SEG_FIN ci dessus)
Ces bits sont évidemment cumulables.

Q Champ Fenêtre :

J Taille : 16 bits.

J Abréviation : W.

J Valeur : Taille, en octets, à partir de l'octet ACK, de la fenêtre d'émission allouée au récepteur de ce
segment.

p234
Ch Ch k
10 - LE PROTOCOLE TCP
Transmission Control Protocol
NTway.com Q Champ Checksum :
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
J Taille : 16 bits.

J Abréviation : Néant.

J Valeur : Le checksum considéré concerne le segment TCP complet (en-tête et données), ainsi qu'un
pseudo en-tête rajouté pour le calcul du checksum et composé d'informations relevant de IP :

Adresse INTERNET de l'émetteur (32 bits);


Adresse INTERNET du destinataire (32 bits);
Octet PROT de l'entête IP (8 bits cadrés à droite sur 16 bits);
Longeur totale du segment (16 bits).

Le calcul est fait comme pour IP en tenant compte d'un champ CHECKSUM initial de 0x0000 et en
additionnant les mots de 16 bits du segment et du pseudo entête (96 bits) un à un modulo 65535. Le
checksum est alors le complément à un (ou l'inverse) de la somme ainsi trouvée.
Cette méthode permet de contrôler le checksum en faisant d'un seul coup la somme modulo 65535
de tous les mots concernés et de vérifier qu'elle donne 0xFFFF (ou 0x0000).

Q Pointeur de fin de données urgentes.

J Taille : 16 bits.

J Abréviation : URGPTR.

J Valeur : Ce champ indique la valeur courante du pointeur de données urgentes, exprimé comme la
position relative du premier octet suivant les données urgentes par rapport au premier octet de
données du segment courant.
Ce champ n'est bien sûr valide que si le bit URG est positionné à 1.

p235
10 - LE PROTOCOLE TCP
Transmission Control Protocol
NTway.com Q Champ Options :
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
J Taille : Variable, de 0 à 40 octets. La longueur effective de la partie option est 4*(longueur_d'en-tête-
5) octets.

Q Analyse du champ option :

J Le champ est constitué d'une succession d'options élémentaires de longueurs variables.

J Chaque option élémentaire est elle-même constituée :

Q Soit d'un seul octet (options de longueur fixe),


Q Soit d'un octet définissant l'option, suivi d'un octet de longueur et des DATAs de l'option.
J Longueur totale de l'option, exprimée en octets, y compris les deux octets type et

longueur. Ce champ vaut donc au minimum 2.

J Le champ option doit être complété de façon à se terminer sur une limite de 32 bits (la taille du
header est d'ailleurs exprimée en multiples de 32 bits).

p236
10 - LE PROTOCOLE TCP
Transmission Control Protocol
NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Format du champ options TCP

Option Option Option Option Padding


1 2 i k éventuel

Une option peut être constituée d'un seul octet :


(les divisions correspondent à des positions binaires)

b0 b0 b0 b0 b4 b5 b6 b7

CF classe numéro

Une option peut aussi être constituée de plusieurs octets :


(les divisions correspondent à des positions binaires)

b0 b0 b0 b0 b4 b5 b6 b7 b0 b0 b0 b0 b4 b5 b6 b7

CF classe numéro longueur totale valeur ...

F05-047

Q Différentes options de TCP :

J 0 Fin d'options (option tenant sur un octet)


J 1 NOP (option tenant sur un octet), sans effet
J 2 Taille maximale des segments

p237
10 - LE PROTOCOLE TCP
Transmission Control Protocol
NTway.com J Présentation et codage des options TCP :
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Q Option 0 (Fin d'option)

J Format : Longueur fixe d'un octet.

J Rôle : Terminer l'analyse des options.

Q Option 1 (NOP)

J Format : Longueur fixe d'un octet.

J Rôle : Aucun, à sauter.

Q Option 2 (Taille maximum des segments)

J Format : 4 octets.

J Rôle : Permet à l'émetteur de cette option d'indiquer au destinataire la taille maximale des
segments que lui-même (émetteur) accepte de recevoir par la suite. Ce champ est présent dans le
TCP_SEG_SYN ainsi que dans le TCP_SEG_SYN_ACK mais cette double présence signifie que
chacun informe l'autre de ses exigences (qui devront être respectées) sans que cela constitue une
négociation pour une valeur commune.

J Valeur : Taille segment sur deux octets, exprimée en octets.

p238
10 - LE PROTOCOLE TCP
Transmission Control Protocol
NTway.com J Encapsulation de X255 sur TCP (XOT) :
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Q X25 a besoin d'une couche 2 fiable et utilise d'habitude HDLC. Or on a parfois besoin de
transporter des paquets X25 sur des réseaux TCP/IP. La méthode est alors d'encapsuler
les paquets X25 dans des TPDU TCP.

Q TCP fournit un service fiable "flots d'octets" continu, X25 exige de remettre à la couche du
dessous (et de recevoir) des paquets séparés. C'est XOT qui fournit ce service entre X25 et
TCP. Le champ principal de cet en-tête est un champ longueur, utilisé pour séparer les
paquets X25 au milieu du flot d'octets de TCP.
X25 SUR TCP
RFC 1613

X25 X25
XOT XOT

TCP TCP

IP IP
HDLC 2 2 HDLC

F05-114

p239
10 - LE PROTOCOLE TCP
Transmission Control Protocol
NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

X25 SUR TCP


RFC 1613

X25 X25
XOT XOT

TCP TCP

IP IP
HDLC 2 2 HDLC

F05-114

p240
NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

- 11 -
LE PROTOCOLE SNMP
SIMPLE NETWORK MANAGEMENT
PROTOCOL

p241
11 - LE PROTOCOLE SNMP

NTway.com J OBJECTIFS
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Q Le protocole SNMP (Simple Network Management Protocol) est relativement récent (la
dernière version des RFC le concernant date de mai 1990) et est relatif à la gestion des
réseaux TCP-IP. Son intérêt essentiel réside dans sa très grande généralité et dans la
possibilité qu'il offre d'être étendu, généralisé, au moyen de l'usage d'objets privés.

Q SNMP devrait permettre aussi bien l'administration de machines TCP-IP que de modems,
de ponts ou de routeurs spécialisés.

Q Les principaux RFC concernés sont :

J RFC 1155, pour définir la structure des informations de gestion (SMI : Structure of Management
Information);

J RFC 1156, pour définir la base de gestion elle même (MIB, Management Information Base);

J RFC 1157, pour définir le protocole SNMP lui même;

J RFC 1158, qui définit une nouvelle version de la MIB (MIB II).

p242
11 - LE PROTOCOLE SNMP

NTway.com J PRINCIPE GENERAL


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Les concepts.

Q SNMP est fondé sur plusieurs idées simples :

J il existe des "Network Agents" qui sont des composants administratifs (logiciels) résidents dans
les composants administrables du réseau (couches IP, couche TCP, routeur, appareil de
surveillance, .... );

Q il existe également des "Network Management Station" destinées à traiter des informations
administratives en provenance des "Network Agents" et d'offrir des services de gestion à
des opérateurs;
J chaque "Network Agent" maintient une image virtuelle (appelée MIB, pour Management Information
Base) constituée d'un ensemble d'objets traduisant des éléments administrables du réseau; les
types d'objets contenus dans les MIB, leurs contenus, les techniques d'identification des objets et
les MIB sont standardisés par les RFC INTERNET;

p243
11 - LE PROTOCOLE SNMP

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Q Le protocole SNMP est simplement le protocole de dialogue entre un "Network Manager"


et un "Network Agent". L'idée essentielle de ce protocole est de permettre trois actions :

J l'interrogation par le "Network Manager" du contenu de la MIB d'un "Network Agent";

J la modification par le "Network Manager" du contenu de la MIB d'un "Network Agent";

J l'émission spontanée (auusi rare que possible) par le "Network Agent" de messages d'information
destinés au "Network Manager"; chaque fois que possible, il sera en effet préféré que le "Network
Manager" interroge l'agent.

Q Le protocole ne prévoit pas d'ordres sophistiqués comme par exemple les ordres de
rechargement à distance (reboot). L'idée est en effet de dire que tout ordre doit pouvoir se
ramener aisément à la modification d'un paramètre de la MIB. La solution choisie est donc
certainement la plus générale.

p244
11 - LE PROTOCOLE SNMP

NTway.com Les relations avec l'administration OSI


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Q L'histoire de l'administration TCP-IP est assez récente :

J Une première étape, constituée à partir de mai 1987 par le protocole SGMP (Simple Gateway
Management Protocol);

J Une deuxième étape, à partir de mars 1988, est franchie avec la version expérimentale de SNMP. A
ce moment, deux grandes idées dominent :

Q Conserver un protocole simple et pragmatique;

Q Garder une compatibilité maximale avec les développements en cours au sein de l'ISO : CMIS
et CMIP. En parallèle de SNMP a donc été développé un protocole CMOT. SNMP et CMOT
devaient garder le maximum de compatibilité et s'appuyer si possible sur la même MIB, ou du
moins sur des MIB compatibles.
J Common Management Information Protocol (CMIP) et Common Management
Information Service (CMIS).
J CMIS/CMIP On Tcp/ip (CMOT).

J Au bout d'un an, l'importance des divergences est reconnue (sophistication de CMIS/CMIP face à la
rusticité de SNMP; volonté de l'IAB -Internet Authority Board- d'aboutir rapidement face aux
procédures très formelles de l'ISO, ...).

J Depuis 1989, les deux concepts ont poursuivi leur route indépendamment. SNMP est stabilisé
depuis mai 1990 et CMOT continue à être étudié.

p245
8 - SNMP
MODELE D'ADMINISTRATION

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma Le modèle d'administration SNMP

ressources réelles
quelconques

logiciel "agent" agent

M.I.B. : ressources réelles


modélisées par l'agent

protocole d'administration

UDP/IP

logiciel "manager"

Applications
d'administration

Interface utilisateur
Stations d'administration

Remarque
Ce modèle, utilisé pour l'administration des réseaux, systèmes et
applications est simple et identique dans toutes les approches
privées ou standardisées. Il repose sur trois grands composants :
la MIB, l'agent et le manager.

p246
11 - LE PROTOCOLE SNMP

NTway.com Q Une autre caractéristique rapproche SNMP de l'ISO : la totalité de la MIB et des éléments
Tél: 0-22-22-50-98 protocolaires de SNMP est définie selon la syntaxe ASN.1. En réalité, pour respecter le
E-mail: ntway@iam.net.ma
souci de simplicité affiché par les objectifs initiaux, seul un sous ensemble de ASN.1 est
autorisé.

Q Il faut noter par ailleurs que les principaux travaux en cours (OSI-NM Forum, par exemple),
s'intéressent plus à l'interconnexion de "Network Managers" qu'à celle entre "Manager" et
"Agent".

J LE PROTOCOLE SNMP.

Les échanges protocolaires.

Q SNMP s'appuie sur UDP et n'utilise pas de phase de connexion déconnexion. Les
datagrammes utilisés sont au nombre de cinq :

J GetRequest-PDU;
J GetNextRequest-PDU;
J GetResponse-PDU;
J SetRequest-PDU;
J Trap-PDU;

p247
11 - LE PROTOCOLE SNMP

NTway.com Q Les ports utilisés sont normalement :


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
J 161 pour les échanges normaux;

J 162 pour les messages spontanés.

Q Les messages SNMP sont limités à 484 octets.

Interrogation de la MIB

Requête d'interrogation de MIB :

Network Agent Network Manager

M.I.B
GetRequest-PDU (obj,obj, ...)

GetResponse-PDU (val,val, ...)

F05-048

Q Le PDU GetRequest contient une liste d'identificateurs d'objets et le GetResponse contient


la liste valorisée avec la valeur associée à chacun des objets. En cas d'anomalie, la
réponse contient un code d'erreur. Seuls les objets marqués "READ" dans la MIB sont
ainsi interrogeables.
p248
11 - LE PROTOCOLE SNMP

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Q Les requêtes et les réponses sont corrélées par un identifiant de requête fourni par le
Manager et recopié par l'Agent dans la réponse. Cet identifiant permet ainsi la détection
des pertes ou duplications éventuelles.

Balayage de la MIB :

Requête de déplacement dans la MIB :

Network Agent Network Manager

M.I.B
GetNextRequest-PDU (obj,obj, ...)

GetResponse-PDU (val, val, ...)

F05-049

Q Le PDU GetNextRequest permet de trouver l'objet qui suit immédiatement dans la MIB
l'objet référencé (ou les objets référencés). L'ordre utilisé est l'ordre lexicographique. Nous
verrons ultérieurement que les identifications d'objets étant conçues de façon
hiérarchiques, l'ordre lexicographique est pertinent car il permet le balayage de l'arbre des
objets frère par frère.

p249
11 - LE PROTOCOLE SNMP

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Modifictation de la MIB :

Requête de modification de la MIB :

Network Agent Network Manager

M.I.B
SetRequest-PDU ((obj,val),(obj,val), ...)

GetResponse-PDU (val, val, ...)

F05-050

Q Le PDU SetRequest permet de modifier le contenu des objets fournis dans la requête.
Seuls les objets marqués "WRITE" dans la MIB sont manipulables.

p250
11 - LE PROTOCOLE SNMP

NTway.com Fourniture d'informations spontanées :


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Fourniture d'information spontanée :

Network Agent Network Manager

M.I.B
Trap-PDU (infos)

F05-051

Q Peu de Trap-PDU sont prévus officiellement aujourd'hui :

J Coldstart, pour signifier une réinitialisation complète de l'agent;


J Warmstart, pour signifier une réinitialisation de la machine de l'agent, mais pas de l'agent lui-même;
J Linkdown, pour signifier une rupture de lien;
J Linkup, pour signifier le retour à la normale d'une ligne;
J AuthentificationFailure, comme son nom l'indique;
J EgpNeighborLoss, pour signifier la rupture de la liaison avec un voisin EGP;
J EnterpriseSpecific, pour transporter des informations spontanées propres à une entreprise;

p251
11 - LE PROTOCOLE SNMP

NTway.com J LA SECURITE DES ECHANGES PROTOCOLAIRES :


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Q La sécurité des échanges protocolaires n'est pratiquement pas assurée aujourd'hui. Au
moment de la stabilisation du protocole SNMP, deux concepts ont été introduits :

J la notion de "Communauté" (ou Community) qui représente un agent et un ou plusieurs managers


pouvant l'interroger ou le commander. Chaque communauté est identifiée par un nom, transporté
dans tous les PDU.

J la notion de schéma d'authentification qui prévoit la possibilité d'appliquer une procédure


d'authentification aux PDU. Ces procédures d'authentification dépendent de la communauté et ne
sont pas définis dans le standard SNMP.

Q Cette sécurité est faible (renforcée en SNMP V2 et V3 par une authentification)

Q Une attention toute particulière doit donc être apportée aux risques induits par des
managers "pirates" qui s'adresseraient à des agents pour en obtenir des informations ou
pour en modifier des variables dans l'agent.

p252
11 - LE PROTOCOLE SNMP

NTway.com J LE CODAGE DES PDU :


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Q Les PDU sont définis ci-dessous conformément à la syntaxe ASN.1. Le codage
(sérialisation) lui-même est fait en utilisant les règles d'encodage de base de ASN.1.

D'abord la structure de message SNMP elle-même :

Message SNMP :

Message ::=
SEQUENCE {
version -- une seule version : version-1
actuellement
INTEGER {
version-1(0)
},

community -- nom de la "communauté", pour


la sécurité
OCTET STRING,

data -- données issues de


l'application du schéma
ANY -- d'authentication utilisé
}
F05-052

p253
11 - LE PROTOCOLE SNMP

NTway.com J LE CODAGE DES PDU :


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Q Le champ "data" est le résultat de l'application du schéma d'authentification sur le PDU. La
fonction d'authentification dispose du nom de la "communauté" concernée ainsi que des
adresses IP et ports sources et destinations. Dans le plupart des cas, ce champ est en fait
directement le PDU, mais il serait possible d'y trouver le PDU chiffré, accompagné d'une
clé aléatoire, par exemple, .... .

Puis les PDU :

Les cinq PDU SNMP :

PDUs ::=
CHOICE {
get-request
GetRequest-PDU,

get-next-request
GetNextRequest-PDU,

get-response
GetResponse-PDU,

set-request
SetRequest-PDU,

trap
Trap-PDU
}
F05-053

p254
11 - LE PROTOCOLE SNMP

NTway.com
Tél: 0-22-22-50-98 Définition des types de PDU :
E-mail: ntway@iam.net.ma
GetRequest-PDU ::=
[0]
IMPLICIT PDU

GetNextRequest-PDU ::=
[1]
IMPLICIT PDU

GetResponse-PDU ::=
[2]
IMPLICIT PDU

SetRequest-PDU ::=
[3]
IMPLICIT PDU specific-trap -- code specifique, toujours présent
INTEGER,

PDU ::=
SEQUENCE { time-stamp -- temps écoulé depuis le dernier (re) démarrage du réseau
request-id TimeTicks,
INTEGER,

error-status -- parfois ignoré variable-bindings -- information pertinente relative au TRAP


INTEGER { VarBindList
noError(0), {
tooBig(1), VarBind ::=
noSuchName(2), SEQUENCE {
badValue(3), name
readOnly(4), ObjectName,
genErr(5)
}, value
ObjectSyntax
error-index -- parfois ignoré }
INTEGER,
VarBindList ::=
variable-bindings SEQUENCE OF
VarBindList VarBind
} F05-54b

Trap-PDU ::=
[4]
IMPLICIT SEQUENCE {
enterprise -- type de l'objet générant le TRAP (voir sysObjectID)
OBJECT IDENTIFIER,

agent-addr -- adresse de l'objet générant le TRAP


NetworkAddress,

generic-trap -- type de TRAP


INTEGER {
coldStart(0),
warmStart(1),
linkDown(2),
linkUp(3),
authenticationFailure(4),
egpNeighborLoss(5),
enterpriseSpecific(6)
},
F05-054a

p255
11 - LE PROTOCOLE SNMP

NTway.com J LES MIB


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Q Cette normalisation est représentée par l'OIT (Object Information Tree) définit par l'ISO et
le CCITT.

Q L'OIT est une base d'information hiérarchisée. On peut la représenter sous la forme d'un
arbre dont la racine ne porte pas de nom et se ramifie en trois branches chacune identifiée
par un numéro :

J une branche CCITT (numéro 0) introduisant les objets administrés par le CCITT

J une branche ISO (numéro 1) introduisant les objets administrés par l'ISO

J une branche (numéro 2) JOINT-ISO-CCITT

Q La branche (ou nœud) ISO comprend elle-même plusieurs branches dont :

J une branche ORG (numéro 3) pour les autres organisations nationales ou internationales.

p256
11 - LE PROTOCOLE SNMP

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma Q La branche (ou nœud) ORG se divise elle aussi en plusieurs branches dont :

J une branche administrée par le DOD (Department of Defence - numéro 6 -)

J Le DOD lui même a affecté la branche numéro 1 à l'IAB (Internet Authority Board).

Q Un point quelconque de l'arborescence est ainsi défini par la succession de numéros de


chacun des nœuds traversés pour atteindre l'objet :

J Le nœud INTERNET est ainsi référencé 1.3.6.1

Q Le nœud INTERNET comporte lui-même plusieurs ramifications dont celle des MIB :

J Le nœud MGMT (numéro 2 ) contient la ou les MIB standard. Un seul sous-nœud existe et
représente la MIB officielle (MIB I et MIB II sont en fait deux versions successives de la MIB
officielle et ne représentent pas deux nœuds distincts).

J Le nœud numéro 3 (EXPERIMENTAL) permet la prise en compte d'expérimentations sur certaines


MIB spécifiques sous le contrôle de l'IAB.

J Le nœud PRIVATE (numéro 4) est le nœud des MIB privées (HP, BULL, SUN,…). Celles-ci, une fois
validées par l'IAB peuvent parfaitement passer sous le nœud numéro 2 des MIB Standard.

p257
11 - LE PROTOCOLE SNMP

NTway.com OIT : Arbre des types d'objets (ASN.1) :

Tél: 0-22-22-50-98 <root> <0:CCITT> <0:AVIS> <0:A>


E-mail: ntway@iam.net.ma
<26:Z>
<1:QUESTION> ...
<2:ADM>
<208:FR>
<3:NTW>

<1:ISO> <0:NORMES> ...

<1:AUTORITIES> ...
<2:MEMBRES>
<250:AFNOR>
<3:ORG> <0:...
<1:...
<2:...
<3:...
<4:...
<5:...
<6:DOD> <0:...

<1:INTERNET>
Structure des objets
administrés par SNMP

<2:JOINT ISO-CCITT>
F05-055

F05-057
Structure de l'arbre INTERNET :
<1.3.6.1: INTERNET> <1:DIRECTORY> <0:...>
<2:MGMT> <1:MIB>
MIB standard
MIB I puis
MIB II

<3:EXPERIMENTAL>

<x:Expérimentation_x> MIB Expérimental

<4:PRIVATE> <1:ENTERPRISES>
<i:Société x>

<j: Société y>


MIB privée de
la société y

p258
11 - LE PROTOCOLE SNMP

NTway.com Structure de premier niveau mib-1 :


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
<mib> <1:system> groupe décrivant le système de l'agent

<2:interfaces> groupe traitant des accès réseau

<3:at> groupe traitant des tables de translation d'adresse (ARP)

<4:ip> groupe traitant des événements IP

<5:icmp> groupe traitant des événements ICMP

<6:tcp> groupe traitant des événements TCP

<7:udp> groupe traitant des événements UDP

<8:egp> groupe traitant des événements EGP


F05-058

Structure de premier niveau mib-2 :

<mib> <1:system> groupe décrivant le système de l'agent

<2:interfaces> groupe traitant des accès réseau

<3:at> groupe traitant des tables de translation d'adresse (ARP)


(nettement revu par rapport à MIB I)

<4:ip> groupe traitant des événements IP

<5:icmp> groupe traitant des événements ICMP

<6:tcp> groupe traitant des événements TCP

<7:udp> groupe traitant des événements UDP

<8:egp> groupe traitant des événements EGP

<9:cmot> groupe traitant des événements CMOT ]

<10:transmission>

<11:snmp> groupe traitant des événements SNMP F05-059

p259
11 - LE PROTOCOLE SNMP

NTway.com Q Les objets présents dans ces différents groupes sont en grand nombre et définis de façon
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma très précise.

Q Les tableaux suivants fournissent à titre d'exemple la description de l'arborescence


relative à IP :
Objets du groupe IP :

<01:ipForwarding> R/O INTEGER {


gateway(1), -- flag indiquant que l'agent peut être IS
host(2) } -- l'agent ne peut pas être intermédiaire

<02:ipDefaultTTL> R/W INTEGER -- TTL par défaut

<03:ipInReceives> R/O Counter -- Compteur de datagrammes IP reçus

<04:ipInHdrErrors> R/O Counter -- Compteur de datagrammes IP reçus en erreur

<05:ipInAddrErrors> R/O Counter -- Compteur de datagrammes IP reçus avec des


-- adresses destinataires invalides

<06:ipForwDatagrams> R/O Counter -- Compteur de datagrammes "commutés"

<07:ipInUnknownProtos> R/O Counter -- Compteur de datagrammes écartés pour cause


-- de protocole inconnu

<08:ipInDiscards> R/O Counter -- Compteur de datagrammes corrects mais non


-- commutés pour causes internes.

<09:ipInDelivers> R/O Counter -- Compteur de datagrammes correctement remis à


-- leur destinataire local.

<10:ipOutRequests> R/O Counter -- Compteur de datagrammes remis par des


-- utilisateurs locaux à la couche IP

<11:ipOutDiscards> R/O Counter -- Compteur de datagrammes à émettre corrects


-- mais écartés pour raisons diverses.

<12:ipOutNoRoutes> R/O Counter -- Compteur de datagrammes à émettre écartés


-- pour cause de route inexistante.

<13:ipReasmTimeout> R/O INTEGER -- Timeout d'attente de réassemblage

<14:ipReasmReqds> R/O Counter -- Compteur de datagrammes fragmentés reçus

<15:ipReasmOKs> R/O Counter -- Compteur de datagrammes reçus à réassembler


-- réassemblés avec succès.

<16:ipReasmFails> R/O Counter -- Compteur de datagrammes reçus à réassembler


-- mais dont le réassemblage a échoué.

<17:ipFragOKs> R/O Counter -- Compteur de datagrammes émis fragmentés.

<18:ipFragFails> R/O Counter -- Compteur de datagrammes émis à fragmenter


-- mais dont la fragmentation a échoué.

<19:ipFragCreates> R/O Counter -- Compteur de fragments émis issus de la


-- fragmentation de datagrammes à émettre

<20:ipAddrTable> R/O SEQUENCE OF IpAddrEntry


IpAddrEntry ::= SEQUENCE {
ipAdEntAddr -- adresse IP
IpAddress,
ipAdEntIfIndex -- index de l'interface IP correspondante
INTEGER,
ipAdEntNetMask -- subnet mask
IpAddress,
ipAdEntBcastAddr
INTEGER }

<01:ipAdEntAddr> R/O IpAddress

<02:ipAdEntIfIndex> R/O INTEGER

<03:ipAdEntNetMask> R/O IpAddress

<04:ipAdEntBcastAddr> R/O INTEGER

F05-060a

p260
11 - LE PROTOCOLE SNMP

NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

<21:ipRoutingTable> R/W SEQUENCE OF IpRouteEntry


-- Table de routage IP

<01:ipRouteEntry> R/W IpRouteEntry


-- Une entrée de la table de routage IP

IpRouteEntry ::= SEQUENCE {


ipRouteDest -- Adresse IP destinataire
IpAddress,
ipRouteIfIndex -- Index de l'interface de sortie à utiliser
INTEGER,
ipRouteMetric1 -- "longueur" de la route principale (ou -1)
INTEGER,
ipRouteMetric2 -- "longueur" de la 1ère route de backup (ou -1)
INTEGER,
ipRouteMetric3 -- "longueur" de la 2ème route de backup (ou -1)
INTEGER,
ipRouteMetric4 -- "longueur" de la 3ème route de backup (ou -1)
INTEGER,
ipRouteNextHop -- adresse IP du suivant sur la route
IpAddress,
ipRouteType -- type de route (voir plus bas)
INTEGER,
ipRouteProto -- protocole ayant permis la connaissance de la
INTEGER, -- route ...
ipRouteAge -- temps (en secondes) écoulé depuis la dernière
INTEGER -- mise à jour des infos relatives à cette route
}

<01:ipRouteDest> R/W IpAddress

<02:ipRouteIfIndex> R/W INTEGER

<03:ipRouteMetric1> R/W INTEGER

<04:ipRouteMetric2> R/W INTEGER

<05:ipRouteMetric3> R/W INTEGER

<06:ipRouteMetric4> R/W INTEGER

<07:ipRouteNextHop> R/W IpAddress

{ other(1),
invalid(2),
direct(3),
remote(4) }

<09:ipRouteProto> R/O INTEGER


{ other(1),
local(2),
netmgmt(3),
icmp(4),
egp(5),
ggp(6),
hello(7),
rip(8),
is-is(9),
es-is(10),
ciscoIgrp(11),
bbnSpfIgp(12),
oigp(13) }

<10:ipRouteAge> R/W INTEGER

F05-060b

p261
11 - LE PROTOCOLE SNMP

NTway.com Q Un constat s'impose : SNMP s'intéresse surtout aux niveaux 3 et 4 de l'architecture, et


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma relativement peu aux niveaux inférieurs et supérieurs (LAN MANAGER, par exemple,
s'intéresse aux niveaux supérieurs, mais peu aux niveaux 1 à 4). Les niveaux 1 et 2 sont
donc pour l'essentiel laissés aux fournisseurs d'équipements.

J Les instances d'objet.

Q Les paragraphes précédents montrent bien comment est identifié un type d'objet précis.
Ainsi, le type IpRouteMetric1 est-il identifié comme {iso org dod internet mgmt mib ip
ipRoutingTable ipRouteEntry ipRouteMetric1 }, soit encore : 1.3.6.1.2.1.4.21.1.3.

Q Cependant, dans une MIB donnée, il existe à l'évidence plusieurs entrées de tables de
routage et une GetRequest-PDU voulant obtenir la longueur d'une route précise doit être
capable d'identifier l'occurence qui l'intéresse.

Q Pour ce faire, SNMP définit la façon d'identifier une occurence d'objet pour chaque type.
En général, lorsque une seule occurence existe, l'identification consiste à suffixer le type
avec le chiffre 0. Ainsi, pour connaître la durée écoulée depuis le dernier startup d'un
agent, il suffit de demander la valeur de l'objet 1.3.6.1.2.1.1.3.0.

p262
11 - LE PROTOCOLE SNMP

NTway.com Instances de tables d'interfaces.


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Q Les instances de tables d'interfaces sont suffixées par l'index de l'interface.

Instances de tables d'adresses IP.

Q Les instances d'objets sont obtenues en suffixant le type par les 4 octets de l'adresse IP
désirée. Ainsi, pour obtenir le subnet mask associé avec l'adresse 192.93.10.5, il suffit de
désigner ipAdEntMask.192.93.10.5 (soit 1.3.6.1.2.1.4.20.1.3.192.93.10.5).

Instances de tables de routage IP.

Q Les instances d'objet sont là encore obtenues en suffixant le type par l'adresse IP. Pour
permettre de connaître la longueur de la route permettant d'atteindre 192.93.10.6, il suffit
de demander la valeur de l'objet de type ipRouteMetric1 et de valeur
ipRouteMetric1.192.93.10.6.

J Il faut noter que l'interprétation d'une instance ne peut se faire qu'en connaissant le type auquel elle
appartient.

Instances de connexions TCP.

Q Les instances d'objets relatifs à des connexions TCP sont désignées en suffixant le type
par les 4 octets de l'adresse IP locale, puis l'entier désignant le port local, puis les quatre
octets désignant l'adresse IP distante, puis l'entier désignant le port distant.

p263
11 - LE PROTOCOLE SNMP

NTway.com Instances de tables d'interfaces.


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma
Q Les instances de tables d'interfaces sont suffixées par l'index de l'interface.

Instances de tables d'adresses IP.

Q Les instances d'objets sont obtenues en suffixant le type par les 4 octets de l'adresse IP
désirée. Ainsi, pour obtenir le subnet mask associé avec l'adresse 192.93.10.5, il suffit de
désigner ipAdEntMask.192.93.10.5 (soit 1.3.6.1.2.1.4.20.1.3.192.93.10.5).

Instances de tables de routage IP.

Q Les instances d'objet sont là encore obtenues en suffixant le type par l'adresse IP. Pour
permettre de connaître la longueur de la route permettant d'atteindre 192.93.10.6, il suffit
de demander la valeur de l'objet de type ipRouteMetric1 et de valeur
ipRouteMetric1.192.93.10.6.

J Il faut noter que l'interprétation d'une instance ne peut se faire qu'en connaissant le type auquel elle
appartient.

Instances de connexions TCP.

Q Les instances d'objets relatifs à des connexions TCP sont désignées en suffixant le type
par les 4 octets de l'adresse IP locale, puis l'entier désignant le port local, puis les quatre
octets désignant l'adresse IP distante, puis l'entier désignant le port distant.

p264
NTway.com
Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

- 12 -
IP version 6

p265
12 - IP VERSION 6

NTway.com J CONCEPT ET ETAT ACTUEL


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Q L’explosion de l’Internet a deux conséquences :

J la consommation des adresses IP s’est fortement accélérée ces dernières années.

J la taille des tables de routage des équipements de l’Internet qui doivent connaître toutes les routes
mondiales (full routing) est devenue gigantesque.

Q Il y a 4 ou 5 ans IPv6 fut très attendu.

Q On a trouvé des solutions pour faire face à la pénurie :

J Dispositif de translation d’adresse.

J Protocole DHCP (Dynamic Host Configuration Protocol)

J Le CIDR (Classless Interdomain Routing), qui a permis de contenir l’explosion des tables de
routage Internet.

J Enfin, non directement lié au problème de pénurie d’adresse, l’usage de produit comme les pare-
feux, les logiciels de chiffrement viennent palier les limites d’IPv4 en sécurité.

p266
12 - IP VERSION 6

NTway.com J CONCEPT ET ETAT ACTUEL :


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma

Q Caractéristiques de IPv6

J Une adresse sur 16 octets au lieu des 4 octets de IPv4.

J Une partie de cette adresse sera constituée de l’adresse MAC de l’équipement : 6 octets.

J Une partie sera consacrée à l’organisation par zone géographique et/ou par prestataire de service.

J L’en-tête du paquet IPv6 est simplifié et inclut un champs d’extension pour les fonctionnalités
optionnelles (sécurité, source routing…)

J Nouvelles fonctionnalités du protocole :

Q La sécurité : Fonctions d’authentification/intégrité des données (RFC 1826 et 1829)


Q Le Source Routing : routage en fonction de l’adresse source grâce au SDRP (Source
Demand Routing Protocol)
Q L’autoconfiguration des équipements : rendue possible par l’utilisation de DHCP (RFC 1541)
Q Le multipoint (ou multicast) : inclus de façon native pour les stations et les routeurs utilisant
IPv6.
Q Gestion des applications en temps réel par le champs d’en-tête Flow Label : nécessite la
mise en œuvre d'un mécanisme de contrôle tel que RSVP (Resource reSerVation Protocol)

p267
12 - IP VERSION 6

NTway.com J CONCEPT ET ETAT ACTUEL


Tél: 0-22-22-50-98
E-mail: ntway@iam.net.ma Q IPv6 aujourd’hui :

J Les standards sont définis

J L'implémentation chez les constructeurs ?


Q Prévu avec la version 12.1 d’IOS - Cisco

Q Prévu dans la version 2000 de Windows NT - Microsoft

J A quand le déploiement ?
Q Le succès attendu du marché des terminaux Internet mobiles conduit les constructeurs à

croire à une explosion des demandes d’adresses IP officielles.

Q La transition de IPv4 vers IPv6 peut se découper en trois phases :


J Phase où seuls des équipements IPv4 existent.

J Phase de coexistence d’équipement IPv4 et IP v6. Trois techniques ont été spécifiées à ce jour :
Q la "double pile IP", chaque équipement implante complètement les deux versions du

protocole.
Q L'encapsulation ou tunneling des paquets IPv6 dans des en-têtes IPv4 pour les acheminer à

travers une infrastructure IPv4.


Q Et la traduction des en-têtes IPv6 en en-têtes IPv4 (voire l’inverse)

J Enfin, phase où seuls subsisteront des équipements IPv6.

p268