Ingnierie des protocoles de communication

Haykal Tej
htej@gmx.de
Inst. Sup. dInformatique et des Technologies de Communication, Hammam Sousse Universit de Sousse
1

Chapitre 1
Gnralits sur les protocoles et les mthodes de gnie de protocoles

Protocoles de communication
Prambule Un protocole est un ensemble de rgles qui gouvernent l'interaction entre processus parallles dans les systmes distribus La conception de protocoles n'est pas une discipline part, elle est lie la fois aux rseaux et l'ingnierie des systmes Dcrire compltement et sans ambigut un protocole est difficile Prouver qu'un protocole est correct est une tche encore plus ardue => Le but du cours n'est pas d'enseigner de nouveaux protocoles, mais de montrer comment on peut (bien) les dcrire

Autopsie d'un accident

Accident du tunnel de Clayton, 1861
A

un train peut entrer dans le tunnel si le smaphore est vert en passant le smaphore, le train le met au rouge automatiquement ; en cas de dfaillance du systme, c'est l'oprateur qui agite un drapeau rouge c'est l'oprateur qui remet le smaphore au vert quand il est sur que le train a quitter le tunnel deux tlgraphes permettent aux oprateurs de s'changer quelques messages Train in tunnel Tunnel is clear Pour plus de scurit, un 3 message est prvu : "Has the train left the tunnel?"

Autopsie d'un accident

Accident du tunnel de Clayton, 1861 : ce qui s'est pass Un train passe le smaphore A (vert), mais le smaphore ne passe pas au rouge. L'oprateur ragit : il envoie le message "Train in tunnel" et agite un drapeau rouge pour arrter les trains suivants. Cependant, un 2 train est arriv trop vite et est pass au vert. Heureusement, le conducteur a entrevu le drapeau rouge in extremis. Un 3 train arrive et s'arrte L'oprateur envoie nouveau le signal "Train in tunnel" pour avertir l'autre qu'il y a 2 trains dans le tunnel. Le protocole n'a pas prvu ce cas. Le problme pour l'oprateur A est maintenant de savoir quand les deux trains ont quitt le tunnel afin d'autoriser le 3 entrer. Pour alerter son collgue, l'oprateur A envoie le signal "Has the train left the tunnel?" Lorsque le premier train sort du tunnel, l'oprateur B rpond "Tunnel is clear" Ne sachant pas si les 2 trains ont quitt le tunnel, l'oprateur A attend un certain temps, puis autorise le 3 train entrer. Malheureusement, le conducteur du 2 train, qui avait vu le drapeau, s'tait arrt dans le tunnel. Aprs un certain temps de rflexion, il a mme fait marche arrire => 23 morts et 176 blesss

Autopsie d'un accident

Accident du tunnel de Clayton, 1861 : conclusion

Il est difficile d'tablir la responsabilit de cet accident. A partir du moment o le 2 train est entr dans le tunnel, il n'y avait plus moyen de rcuprer la situation. L'ensemble des messages disponibles sur les tlgraphes tait incomplet. Le bon sens des oprateurs n'tait pas suffisant.

La raction est toujours la mme : I could not imagine that could ever happen Au dbut, beaucoup d'accidents taient dus au manque de moyens de communication, mais on a constat ensuite qu'il tait surtout trs difficile d'tablir des rgles non ambigus de communication.

Structure d'un protocole

Pour dfinir un protocole, nous devons dfinir un ensemble de rgles :

dfinir comment un message est encod comment une transmission est dmarre et termine, etc

Deux types d'erreurs sont difficiles viter :

la conception d'un ensemble incomplet de rgles (incompltude) la conception de rgles contradictoires (inconsistance)

Cela requiert :

de dfinir tous les lments essentiels du protocole une discipline pour les dfinir en sparant les lments indpendants

La vraie difficult vient du paralllisme. Le nombre de scnarios est en gnral norme et difficile apprhender

1.1. Pourquoi l'ingnierie des logiciels

Historique
Le gnie logiciel, en tant que discipline informatique, est n en octobre 1968 lors dune confrence de lOTAN GarmischPartenkirchen pour rpondre un problme qui devenait de plus en plus vident : dune part le logiciel nest pas fiable, dautre part il est incroyablement difficile de raliser dans les dlais prvus des logiciels satisfaisant leur cahier des charges discipline de lingnieur du logiciel, pour laider dvelopper des systmes informatiques fiables, i.e., satisfaisant leur cahier des charges, dans des dlais raisonnables gnie logiciel comme gnie chimique, gnie lectrique, gnie mcanique = ensemble des techniques, outils et mthodes visant optimiser et rationaliser la production du logiciel et son suivi

Example: auto-pilot
Problem:
Design a part in auto-pilot that avoids collision with other planes.

Solution:
When distance is 1km, give warning to other plane and notify pilot. When distance is 300m, and no changes in the course of other plane were noticed, go up to avoid collision

Problem with solution

Both planes have the same software. Both go up...

This happens in real software!

Some famous bugs

NASA Space Rover, Intel floating point processor, etc. US aircraft went to southern hemisphere and flipped when crossing the equator Air traffic controller: US to Britain.

Hard to predict all behaviours!

It never dealt with problem of 0 degrees longitude. Result: software folded Britain along Greenwich Meridian

Software written for US F-16

accidents when reused in Israeli aircraft flown over the Dear Sea (altitude < sea level)

Year 2000 problem

Yet more such examples

NASA Space Shuttle software (in use since 1980)

16 severity-level 1 software errors 8 remained in code that was used in flights none encountered during flights total size - only 400,000 words

1.1. Pourquoi l'ingnierie des logiciels

Remarque :

les mthodes et techniques issues du gnie logiciel sont imposes par les autorits de certification pour le dveloppement de systmes critiques (avionique, nuclaire) normes de dveloppement de systmes (DO178B)

=> Pour continuer, quelques exemples de systmes complexes

1.1. Pourquoi l'ingnierie des logiciels

Exemples :

Le Systme de Navigation et d'Attaque d'un Rafale =

2 millions de lignes de codes ADA 50 quipements (numriques ou analogiques), 12 calculateurs Contraintes de temps < 1ms combinatoire des modes et des tats leve

Landing System : plus de 1014 tats possibles Side Displays Management : plus de 2.108 tats possibles

1/2 million dinstructions pour une exprience de physique des particules 1 million dinstructions dans un central tlphonique 50 millions dinstructions dans la navette spatiale

Ncessit de rigueur dans la conception

1.1. Pourquoi l'ingnierie des logiciels

Si l'on veut matriser le dveloppement de systmes logiciels fiables, il faut :

rdiger de faon claire les spcifications du systme (ce que l'on attend)
=> comment tre srs que ces spcifications sont compltes ? => comment tre srs que ces spcification sont cohrentes ?

valider/vrifier toutes les tapes du dveloppements

=> a-t-on des moyens de validation/vrification (mathmatiques)?

de rutiliser des sous-systmes dj raliss (mais pas n'importe comment)

=> a-t-on des rgles, des outils pour aider la rutilisation ?

ncessit dune base thorique et dune approche ingnierie (science de lingnieur) du logiciel

1.2. Elments de terminologie

Pour maximiser la qualit d'un systme il faut...

Introduction d'un cycle de vie :

identifier un ensemble d'tape importante dans le dveloppement, et des documents importants analyse de besoins, spcification, conception, programmation, intgration ranger ses tapes dans le temps et les unes par rapport aux autres => cycles en cascade, en V, en Y, en spirale

Pourquoi des techniques formelles

Techniques formelles :

reposent sur des fondements mathmatiques expression mathmatique des objets du dveloppement (le comportement des systmes) expression mathmatique des proprits expression mathmatique des preuves permettent l'analyse (mathmatique) du comportement d'un systme

Remarque :
certains organismes imposent dj l'utilisation de techniques mathmatiques dans le dveloppement de systmes informatiques : dans le domaine de la scurit : obligation d'utiliser des mthodes formelles pour certains niveaux de scurit dans le ferroviaire (mtro Mtor)

Qu'est-ce qu'une technique formelle

Qu'apportent les techniques formelles ?
Les bases mathmatiques (logique, thorie des ensembles) dune technique formelle fournissent les notions de consistance, cohrence

partir d'une spcification S, on ne peut pas dduire "a" et "non a"

Une autre spcification globale activit de spcification vrification d'quivalence Spcification globale Architecture et spcification des composants Programme Axe du dveloppement

Besoins des utilisateurs

vrification de consistance

Qu'est-ce qu'une technique formelle

Qu'apportent les techniques formelles ?
Les bases mathmatiques (logique, thorie des ensembles) dune technique formelle fournissent les notions de correction d'une implmentation par rapport une spcification

il est possible de dcider si un programme P implmente une spcification S

activit de spcification

activit de conception

activit de programmation

Besoins des utilisateurs

Spcification globale

Architecture et spcification des composants

Programme

Axe du dveloppement

vrification

vrification

Qu'est-ce qu'une technique formelle

Que n'apportent pas les techniques formelles ?
La dmonstration de la validit de la spcification globale par rapport aux besoins de l'utilisateur est impossible => parce que les besoins de l'utilisateurs ne sont pas exprims en termes mathmatiques !
activit de spcification Architecture et spcification des composants

Besoins des utilisateurs

Spcification globale

Programme

Axe du dveloppement

validation
Preuves impossibles

Qu'est-ce qu'une technique formelle

En rsum, ce que peuvent et ne peuvent pas les techniques formelles
activit de spcification activit de conception activit de programmation

Besoins des utilisateurs

Spcification globale

Architecture et spcification des composants vrification vrification

Programme

Axe du dveloppement

validation Preuves impossibles vrification

Preuves possibles

1. Qu'est-ce qu'une technique formelle

Quel est l'intrt des techniques formelles ? prcision des langages (due aux aspects mathmatiques) => non ambiguts des notations du fait du substrat mathmatique, une spcification ou un programme n'a qu'une seule signification => diminution du "bruit" dans les spcifications (on ne parle que de ce qui a un sens) possibilit de dtecter les informations inutiles dans une spcification => meilleure comprhension de la spcification par l'quipe de ralisation => meilleure comprhension et dialogue entre clients et concepteurs interprtation "spcification formelle" vers "langage naturel" aise => meilleure documentation des systmes => meilleure rutilisation des composants augmentation de la phase de spcification mais diminution importante de la phase de test, et diminution des corrections en maintenance => rduction globale des cots du logiciel => augmentation de la fiabilit du logiciel

Bref panorama des techniques formelles

Grande diversit des techniques formelles

domaine d'tude de trs nombreux centres de recherche ou grands groupes industriels dans le monde ( l'origine europens) Se diffrencient selon les domaines d'applications

Diffrentes classifications possibles

selon le substrat mathmatique (support de la smantique) logique, thorie des ensemble, thorie des automates, algbre, -calcul... selon le domaine de prdilection base de donnes, systmes ractifs selon la nature du systme de preuve sous-jacent incrmental, automatique... orientes proprits ou orientes modles spcifications excutables ou non

Model Checking

Denotes algorithmic analysis to check that a model (not necessarily finite state) satisfies a specified property In logic, model denotes a structure over which formulas are interpreted

Model checking checks (preferably automatically) whether a given formula holds in a given model

Analyse de modles, Model Checking

Modle M
byte n; proctype Aap() { do :: n++ :: noot!MIES od }

Proprit [] (n<3)

Espace dtats

Analyseur

M |

Explosion dtats.

OUI Proprit satisfaite

NON, + contre_exemple

25

Overview of Automated Verification

SW/HW artifact

Correct?

Correctness
properties

Model Extraction

Translation

Model of
abstraction

System

Temporal logic

Answer +
Checker Engine

Counter-example

Limitations
Appropriate for control-intensive applications with interesting interaction among components

Data remains a problem

Decidability and complexity remains an obstacle

Falsification rather than verification

Model, and not system, is verified Only stated requirements are checked: how to capture correctness in a formal language? Bugs in the model checker

Finding suitable abstractions requires expertise

The Methodology Answer

Formal verification does not aim to produce mathematical certainty of correctness, but to provide a methodology that, when followed, produces more reliable and robust systems

Protocoles de communication

Protocoles de communication
Prambule
Un protocole est un ensemble de rgles qui gouvernent l'interaction entre processus parallles dans les systmes distribus La conception de protocoles n'est pas une discipline part, elle est lie la fois aux rseaux et l'ingnierie des systmes Dcrire compltement et sans ambigut un protocole est difficile Prouver qu'un protocole est correct est une tche encore plus ardue => Le but du cours n'est pas d'enseigner de nouveaux protocoles, mais de montrer comment on peut (bien) les dcrire

Protocoles de Communication
Protocole Rseau:

Les protocoles peuvent etre implments en matriel et/ou logiciel. EIA-232-D est un protocole faisant partie de la couche physique implment en materiel. Les protocoles TCP/IP sont implments en logiciel.

Protocol Data Units (PDU)

Les entits communicantes changent des fragments formatts selon le protocole utilis. Chaque fragment est une unit de donne du protocole (Protocole Data Unit ou PDU) Chaque PDU contient: Header (entte): Spcifie comment traiter et router le reste du PDU Message: le contenu du PDU Trailer (queue) sert en gnral pour le contrle derreurs.
Header Message Trailer

Structure d'un protocole

Pour dfinir un protocole, nous devons dfinir un ensemble de rgles :

dfinir comment un message est encod comment une transmission est dmarre et termine, etc
la conception d'un ensemble incomplet de rgles (incompltude) la conception de rgles contradictoires (inconsistance) de dfinir tous les lments essentiels du protocole une discipline pour les dfinir en sparant les lments indpendants

Deux types d'erreurs sont difficiles viter :

Cela requiert :

La vraie difficult vient du paralllisme. Le nombre de scnarios est en gnral norme et difficile apprhender

Structure d'un protocole

Les Cinq lments d'un protocole

Le service fournir par le protocole Les hypothses sur l'environnement dans lequel le protocole s'excute Le vocabulaire des messages utilis par le protocole Le format de chaque message Les rgles procdurales utilises durant la communication

La 5 partie est la plus dlicate dfinir et la plus difficile vrifier.

Structure d'un protocole

Un exemple 1. Le service :

Transfert de fichiers de texte comme squences de caractres via une ligne tlphonique en se protgeant contre les erreurs de transmission (suppose toutes dtectables) Bidirectionnel : 2 transferts en sens opposs possibles

2. Les hypothses : Compos de 2 utilisateurs et d'un canal de transmission On suppose que chaque utilisateur peut soumettre une requte et attendre qu'elle s'excute Le canal peut modifier les messages, mais pas les perdre, les ddoubler, les rarranger, ni en insrer un autre. 3. Vocabulaire : trois messages ack : un message + un acquit positif nak : un message + un acquit ngatif err : un message erron

Structure d'un protocole

Un exemple (suite) 4. Les formats :

Chaque message a un champ de contrle identifiant le type de message et un champ de donnes avec le code de caractre :
Type PDU is record control : tag, data : char endrecord Type tag is {ack, nak, err}

Structure d'un protocole

Un exemple (suite) 5. Les rgles procdurales :

Soit 2 entits A et B
1. Si la rception prcdente est sans erreur, le prochain message sur le canal oppos contiendra un acquit positif. 2. Si la rception prcdente est errone, le prochain message sur le canal oppos contiendra un acquit ngatif. 3. Si la rception prcdente est errone ou contient un acquit ngatif, le prochain message sera une retransmission du message mis prcdemment; sinon, ce sera un nouveau message 4. Si un utilisateur n'a pas de caractre mettre, il peut envoyer un caractre null 5. A dmarre le transfert.

Structure d'un protocole

Un exemple (suite) Reprsentation des rgles procdurales :
fetch(o) mission

nak(o)

Rception

Attente
receive(i) Action nak(i) ack(i) err

fetch(o)

Protocole correct ?
ack(o) ack(o) nak(o)

Structure d'un protocole

Un exemple (suite) Un scnario d'erreur

Structure d'un protocole

Notion vocabulaire et de format
Type PDU is record control : tag, data : char endrecord Type tag is {ack, nak, err}

Attention : il s'agit de formats abstraits, et non d'un codage

Exemple de codage :
record control : bit, data : ASCII char, parity : bit endrecord + des fonctions de calculs d'erreurs

Structure d'un protocole

Notion de rgles procdurales

Exprimes au niveau d'abstraction adquat (pas de dtail inutile (codage)) Doivent tre compltes, consistantes et non ambigus
=> ncessite un formalisme ou un langage appropri Il n'existe pas de mthode permettant de s'assurer a priori de la compltude et de la consistance des rgles => vrification a posteriori

La difficult vient du paralllisme

=> Les diagrammes de squences ne conviennent pas. Ils permettent au mieux d'illustrer un scnario d'erreur.

Un protocole n'est pas correct dans l'absolu ; un protocole est correct par rapport un ensemble de proprits (la spcification de son service)
=> Ncessit de formaliser les proprits ou le service attendu

Rgles d'ingnierie
Simplicit Concevoir des protocoles lgers Faciles comprendre, implanter, maintenir jour, et souvent plus performants Modularit Une hirarchie de fonctions Un protocole complexe doit tre construit partir de modules plus simples qui interagissent de faon simple et bien dfinie Il ne faut pas mlanger des fonctions indpendantes (p. ex. contrle d'erreur et contrle de flux) dans un mme module Un protocole doit tre indpendant du systme d'exploitation, de l'encodage des donnes, des formats d'adresse, des dbits utiliss Facilite l'ouverture (portabilit), l'extensibilit ou le changement de modules... Un protocole doit tre bien form Pas de sur-spcification : pas de code non excutable Pas de sous-spcification : pas de rception non prvue Born : pas de dbordement de tampon Auto-stabilisant : en cas d'erreur, retour dans un tat stable aprs rcupration

Rgles d'ingnierie
Robustesse Concevoir un protocole qui fonctionne bien dans des circonstances normales est facile C'est l'inattendu qui dfie le concepteur Il faut faire un minimum d'hypothses sur l'environnement Un bon design doit rsister l'volution (vitesse des lignes, taille du rseau, ) Il faut viter l'ajout de fonctions inutiles qui pourraient s'avrer tre un frein une volution ultrieure. Consistance : un protocole peut tre incorrect de plusieurs faons Interblocages (deadlocks) : toutes les entits sont bloques en attente de message Cycles non productifs (livelocks) : le systme boucle indfiniment sans progresser Terminaisons impropres : sans satisfaire certaines conditions

Rgles d'ingnierie
Pour finir : quelques rgles de (bonnes conception) 1. Etre sr que le problme est bien dfini : il faut numrer tous les critres et contraintes avant de commencer 2. Dfinir le service fournir avant de concevoir le protocole le quoi avant le comment 3. Principe KISS (Keep It Simple, Stupid) 4. Sparer les fonctionnalits orthogonales. 5. Un bon design rsout une classe de problmes plutt qu'un problme isol. Ne pas se restreindre inutilement. Ne pas introduire de dtails inutiles. 6. Procder par prototypages de haut niveau avant d'implmenter 7. Implmenter, mesurer les performances, et si ncessaire optimiser. 8. Vrifier que l'implmentation est quivalente au prototype de haut niveau.

Les moyens de description de protocoles

Une premire classification les noncs en langue naturelle (anglais, franais) + des tables et des schmas les plus courants mais les plus ambigues et donc les plus risqus, et ne se prtent pas l'analyse (de compltude, de correction) seul l'il humain peut analyser et corriger ces noncs

les techniques semi-formelles descriptions formates (langue naturelle structure) techniques graphiques la UML => modles entits-relations => de plus en plus utilises => souvent clairs et facilement comprhensibles => mais peut comporter encore des ambiguts (aux marges du formalisme), et ne se prtent toujours pas l'analyse (de compltude, de correction)

Les moyens de description de protocoles

Techniques de description de protocoles : quels besoins ? L'abstraction : permettre une description au bon niveau de dtail => pas de dtails superflus => capturer les aspects importants du protocole

La modlisation des tats et des logiques de changement d'tats

L'indterminisme => au niveau de la spcification => du comportement de l'environement

Les moyens de description de protocoles

Techniques de description de protocoles : quels besoins ?

la causalit en actions (squence)

la concurrence entre actions (paralllisme)

||

a a

b b

la synchronisation
a a

l'analysibilit (outil d'analyse) la non ambigut (une smantique formelle)

=> il n'existe aucun formalisme rpondant compltement ces critres

Les moyens de description de protocoles

FSM simple
Exemple : tat d'un processus

inactif, en attente UC, en attente ressource, actif

+UC? attente ressource -UC? +R? -R?

inactif Activation? attente UC ressource +R? -R? +UC? actif attente UC -UC? Fin!

Les moyens de description de protocoles

FSM simple avec paralllisme
Exemple : le protocole du tunnel de Clayton

Has-the-train-left-the-tunnelv2?
No train V1 No train V2

Tunne-is-clearv2!

Trainv1? Train-in-tunnelv2? Tunne-is-clearv1? Train-in-tunnelv1!

||

Tunne-is-clearv2! Has-the-train-left-the-tunnelv2? Out-trainv2

Has-the-train-left-the-tunnelv1? Has-the-train-left-the-tunnelv2?

Conception et description couches

53

Conception couches des protocoles

Un protocole contient normalement un grand nombre de fonctionnalits Pourrait tre dfini comme un seul programme, mais ceci serait excessivement complexe Le manque de modularit rendrait aussi difficile lchange de modules prfabriqus entre compagnies

54

Couches OSI

Rf: http://www.irisa.fr/armor/lesmembres/cousin/Enseignement/Reseaux-generalites/Cours/4-3.htm

55

Modle de rfrence Open Systems Interconnection

56

Fonctionnement Global

57

Entits OSI

N+1-Protocol Entity
N-SDUs N-SAP N+1-PDUs

N+1-Protocol Entity
N-SDUs N-SAP

N-Service Provider

SAP: Service Access Point

58

Entits OSI
Notion de service : modle en couches

Le service est une dfinition fonctionnelle de l'interface entre couches Liste des primitives avec paramtres Ordonnancement permis des primitives Le service N est une abstraction des couches de protocole infrieures.

Entits OSI
Notion d'environnement : abstraction des couches suprieures et infrieures

Centrage sur une couche N et un protocole N Les couches suprieures sont vues comme des utilisateurs abstraits Les couches infrieures sont vues comme un milieu de transmission. Il dcrit les hypothses qui caractrisent ces couches (pertes, doublons possibles, ) Le protocole N dcrit le fonctionnement des entits N (A et B) en raction aux primitives de service N et aux PDU N venant de l'entit homologue via le milieu de transmission (mdium). L'environnement d'un protocole est compos des utilisateurs et du milieu de transmission.

Service Data Units (SDUs)

Request : Une entit sollicite un service Indication : Une entit est informe d'une demande de service Response : Une entit a rendu le service, si possible Confirmation : Une entit est informe que le service a t rendu

SAP

SAP

REQUEST

INDICATION

Service non confirm

Service confirm

CONFIRMATION

RESPONSE

61

Mode non connect (connectionless)

1 seule phase:

le transfert de donnes

chaque unit de transfert de donnes est achemine indpendamment les entits communicantes ne mmorisent rien ("memoryless"). les messages changes sont auto-suffisants ("selfcontent") pas dacquittement de messages (no ack) exemple: datagrammes en IP

64

Mode Connect (connection-oriented)

3 phases : phase d'tablissement de la connexion phase de transfert de donnes phase de libration de la connexion un contexte (rparti) est partag par les membres de la connexion : par exemple : le numro du paquet permet (facilite) le contrle et la gestion du transfert de donnes : contrle d'erreur, contrle de flux, maintien en squence, etc. les messages changs comportent des informations qui ne sont utilisables que grce la connaissance de ce contexte : par exemple : le numro de paquet / la largeur de la fentre coulissante Exemple de protocole utilisant le mode connect:TCP
65