Chapitre 1
This presentation is the property of its rightful owner.
Sponsored Links
1 / 93

Chapitre 1 PowerPoint PPT Presentation


  • 63 Views
  • Uploaded on
  • Presentation posted in: General

Chapitre 1. Généralités sur les protocoles et les méthodes de génie de protocoles. w3.uqo.ca/luigi. Ce chapitre…. Cycle de développement des protocoles V&V, test Modèles à couches Modèles OSI Connexion ou non Un peu d’histoire Le monde de la normalisation. Sujet du cours. Méthodes de:

Download Presentation

Chapitre 1

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Chapitre 1

Chapitre 1

Généralités sur les protocoles et les méthodes de génie de protocoles

w3.uqo.ca/luigi


Ce chapitre

Ce chapitre…

  • Cycle de développement des protocoles

  • V&V, test

  • Modèles à couches

  • Modèles OSI

  • Connexion ou non

  • Un peu d’histoire

  • Le monde de la normalisation

INF6001 Chap 1


Sujet du cours

Sujet du cours

  • Méthodes de:

    • Spécification

    • Conception

    • Validation

    • Vérification

    • Test

      • De protocoles de communication

INF6001 Chap 1


V rification validation v v et test

Vérification, validation (V&V) et test

  • La V&V est une technique pour s’assurer qu’un système corresponde à ses exigences

  • Une distinction subtile est souvent faite entre

    • Validation: la fonctionnalité du système correspond-elle aux exigences de l’usager (requirements)

    • Vérification: le système, fonctionne-t-il bien?

    • Dont l’acronyme V&V

    • Cependant nous n’utiliseront pas beaucoup cette distinction

  • Test: processus de détection de fautes par exécution sur des cas choisis et comparaison des résultats avec les exigences

INF6001 Chap 1


Sp cifications et exigences

Spécifications et exigences

  • Les mots spécification et exigences sont utilisés dans plusieurs significations

INF6001 Chap 1


Diff rents niveaux de sp cif et cycle de d veloppement

Différents niveaux de spécifet cycle de développement

Spec d’exigences (langue naturelle, notation logique)

Spécification du comportement

Spécification de l’implantation (comportement utilisant des composantes données)

Implantation

Nous pouvons effectuer des V&V et du test entre tous les niveaux

INF6001 Chap 1


Loi dans le g nie logiciel

Loi dans le génie logiciel

  • Le plus tôt qu’on identifie une erreur dans la trajectoire de développement, le moins cher il est de corriger l’erreur

INF6001 Chap 1


Sp cification d exigences ou besoins

Spécification d’exigences ou besoins

  • Ce que le système doit faire pour l’usager, p.ex pour un système téléphonique: (niveaux d’abstraction décroissants)

    • Me permettre de communiquer avec l’appelé si disponible

    • Après avoir signalé un numéro, il doit sonner de l’autre côté ou sinon l’appelant doit recevoir un signal occupé

    • Être au début en état inactif, donner la tonalité au décrochage et passer à un état où il permet de composer un numéro…

  • Donc les exigences peuvent être à plusieurs niveaux d’abstraction, peuvent représenter différents aspects du système

  • Il y a tout un domaine de recherches qui s’appelle

    • Requirement Engineering

  • Nombreuses méthodes de spec développés, p.ex.

    • Use Cases (UML)

    • Use Case Maps

    • Notations logiques (OCL en UML)

    • Diagrammes de transitions d’états…

Spec

d’exigences (langue

naturelle, notation logique)

Spécification du

comportement

Spécification de

l’implantation

(comportement utilisant des

composantes données)

INF6001 Chap 1

Implantation


Sp cification du comportement

Spécification du comportement

  • Décrit le comportement du système en termes de séquences d’interactions possibles avec l’environnement

  • Les modèles à états sont les plus souvent utilisés, p.ex.

    • au début, le système et dans l’état inactif, idle

    • ceci rend possible une transition signalisation, par laquelle le système passe à un état attente

    • il passe puis à l’état sonnerie ou signal occupé

  • La structure interne de la spec est abstraite, ne correspond pas nécessairement à un modèle d’implantation

Spec

d’exigences (langue

naturelle, notation logique)

Spécification du

comportement

Spécification de

l’implantation

(comportement utilisant des

composantes données)

INF6001 Chap 1

9

Implantation


Spec partielle du comportement d un t l ph

Spec partielle du comportement d’un téléph.

CallAlert

StartRinging

Idle

OffHook

DialTone

Dialing

Ringing

OnHook

Click

DialDIgits

Clicks

OffHook

StopRing

Path

Active

Mess. entrée

Mess. sortie

Notation:

INF6001 Chap 1


Sp cification de l implantation

Spécification de l’implantation

  • Semblable à la spec du comportement

  • Mais la spec a une structure interne qui correspond à un modèle d’implantation

    • P.ex. un diagramme à état pour chaque composante

  • Décrit les composantes de l’implantation, etc.

INF6001 Chap 1


V rification ou test entre niveaux

Vérification ou test entre niveaux

  • Il est nécessaire de contrôler tous les suivants, et ces contrôles peuvent être faits par V&V ou test:

    • Que la spec du comportement inclut tout le comportement décrit dans les exigences

      • Possiblement aussi qu’il n’y a pas de comportements additionnels indésirables

    • Que la spec de l’implantation inclut tout le comportement décrit dans la spec du comportement et, au besoin, dans la spec des exigences

    • Que l’implantation inclut tout le comportement décrit dans la spec des exigences et au besoin dans la spec du comportement

  • Le besoin de tous ces contrôles est réduit si les différentes niveaux de specs et d’implantation sont obtenus les uns des autres à l’aide d’outils automatiques ou semi-automatiques

    • p.ex. compilation

INF6001 Chap 1


Placement de la v rification et test

Placement de la vérification et test

  • Dans la plupart des modèles de développement du logiciel, la vérification et surtout le test sont considérés comme étapes finales du processus

  • Elles devraient au lieu être considérées comme activités parallèles à être exécutées à toutes les étapes

    • Pour contrôler la cohérence entre étapes et la complétude de chaque étape

INF6001 Chap 1


Sp cifications formelles

Spécifications formelles

  • Afin de rendre la V&V et le test plus précis et fiables, le concept de spécification formelle a été développé

  • Une spécification formelle d’un système est une spécification du comportement désiré du système, écrite dans une notation fournie d’une base logique,

    • Donc adaptable à des processus de vérification et tests automatisés

  • Une spec formelle peut être prise comme expression d’exigences d’usager

  • Ou une spec formelle peut elle-même être testées ou validée, vérifiée par rapport à des exigences exprimées d’une autre façon (langue naturelle, autre langage formel)

  • Aussi, les specs formelles peuvent être utilisées comme terme de comparaison pour la V&V ou le test

  • À voir… c’est le contenu de ce cours

INF6001 Chap 1


Mod lisation de syst mes informatiques

Modélisation de systèmes informatiques

  • Dans leur réalité physique, les systèmes informatiques sont extrêmement complexes

  • Courants électriques qui circulent dans un système

  • Peuvent être interprétées de façons différentes

  • Afin de les analyser, il est nécessaire d’utiliser des simplifications, des abstractions, des interprétations:

    • Chercher à capturer ce que l’usager peut considérer important à un moment donné

    • Toute simplification, tout modèle

      • Capture certaines propriétés et en ignore autres

      • Capture certaines possibilités d’erreur et en ignore d’autres

      • P.ex. dans ce cours nous ne prendrons pas en considération les aspects temps réel

INF6001 Chap 1


Mod le

Modèle

  • Une spec formelle est un modèle abstrait

  • Un modèle est une entité qui se comporte comme le système réel de certains points de vue

    • P.ex. un modèle d’avion pourrait

      • Être comme l’avion, mais beaucoup plus petit

      • Être comme l’avion, mais ne pas voler

      • Se comporter comme l’avion pour le pilote, mais il ne peut pas avoir des passagers, ne peut pas voler, etc. (simulateur de vol)

    • Donc il est une abstraction

    • Un modèle formel d’un logiciel est une entité mathématique qui a certaines des caractéristiques du logiciel, mais pas toutes

      • P.ex. n’est pas capable de fonctionner à la même vitesse, ne peut pas produire la sortie dans l’exacte forme désirée, etc.

INF6001 Chap 1


Conception et description couches

Conception et description à couches

INF6001 Chap 1


Couches dans logiciels

Couches dans logiciels

Couche n+1

Utilise les services de la couche n et fournit des services à la couche n+2

Couche n

Utilise les services de la couche n-1 et fournit des services à la couche n+1

Couche n-1

Utilise les services de la couche n-2 et fournit des services à la couche n

Services = fonctionnalités

En pratique, les services seront des méthodes ou fonctions

INF6001 Chap 1


Conception couches des protocoles

Conception à couches des protocoles

  • Un protocole peut contenir un grand nombre de fonctionnalités

  • Pourrait être défini comme un seul programme, mais ceci serait excessivement complexe à

    • Implanter

    • Vérifier

    • Tester etc.

  • Le manque de modularité rendrait aussi difficile l’échange de modules préfabriqués entre compagnies

INF6001 Chap 1


Chapitre 1

Expressivité du concept de service

  • Si les couches sont bien conçues, il est possible d’exprimer le service fourni par une couche de manière à cacher le mécanisme interne de la couche

    • P. ex. une pile fournit 12 volt

      • C’est le service qu’elle fournit, qu’elle soit NiCa, NiMh, Alcaline, etc. – n’importe

    • Offrant ce service, elle peut être utilisée dans des moteurs qui ont besoin de ce voltage

    • Le moteur à son tour offre un service, identifié par des paramètres tels que puissance: p.ex. 0.05hp, n’importe son fonctionnement

    • Offrant ce service, il peut être utilisé dans des appareils qui ont besoin de cette puissance: p.ex. des modèles d’auto

INF6001 Chap 1


Expressivit du concept de service

Expressivité du concept de service

  • Pile + moteur = force motrice

  • Moteur + modèle auto = jouet fonctionnel

  • Service sous-jacent + protocole = nouveau service

  • À chaque niveau, on peut oublier le service sous-jacent et utiliser directement le nouveau service

INF6001 Chap 1


Communication entre pairs

Communication entre pairs

The sales manager of company A may need to do a transaction with the sales manager of company B:

I want to buy X amount of product P. Negotiation on prices, etc. may take place:

Manager A

Manager B

negotiation

protocol

INF6001 Chap 1


Fournisseur de service

Fournisseur de service

Since A and B are not in the same place, they must rely on some transport mechanism to transfer the Protocol Data Units (PDUs) between them

Manager A

Manager B

PDUs

Service Data Units

SDUs

Service Data Units

SDUs

Service Provider

INF6001 Chap 1


Couches

Couches

The Service Provider itself must be implemented by communicating entities... it is implemented by admin assistants who write letters. These letters include the simple text provided by the managers into other text such as: Date... Dear Sir... Yours Sincerely... It is then passed to the mailing service provider.

Manager A

Manager B

Service Data Units

Service Data Units

PDUs

Assistant A

Assistant B

Service Data Units

Service Data Units

Service Provider

INF6001 Chap 1


Et encore couches

Et encore couches

The assistant interfaces directly with the secretaries. They include the letters into addressed envelopes and pass them on again to the lower layer service providers...

Manager A

Manager B

Service Data Units

Service Data Units

PDUs

Assistant A

Assistant B

SDU

SDU

Secretary A

Secretary B

SDU

SDU

Service Provider

INF6001 Chap 1


Ajout d en t tes encapsulation

Ajout d’en-têtes (encapsulation)

Manager A

Header1

Payload

PDUs

Assistant A

Header2

Header1

Payload

Secretary A

Header3

Header2

Header1

Payload

Service Provider

INF6001 Chap 1


Chapitre 1

Layered Systems Concepts

  • At each layer, an entity has a message exchange with a peer entity on the other side. This exchange is made up of Protocol Data Units.

    • Hence the term peer protocol

      • Peer-to-peer implies that either side can initiate a session and has equal responsibility

  • Direct transmission of PDUs is not possible (except in extremely simple protocols). An underlying service provider must be invoked, by means of Service Data Units (SDUs).

  • The underlying service provider consists in its own turn of peer entities. To transmit the message coming from the protocol entity above, the lower level peer entity adds a header (or possibly a trailer) to the message. It then passes the message to the level below, who will add another header (trailer), etc.

INF6001 Chap 1


Chapitre 1

Concepts of Layered Systems (Continued . . .)

  • The message and all the headers (trailers) it has acquired will eventually be transmitted between the lowest layer peer entities.

  • As the message moves up on the other side, the headers (trailers) tacked on by peer entities are progressively ‘stripped’ at each level

    • secretaries will strip the envelopes, assistants will strip Date... Dear Sir... Yours Sincerely

    • highest level entity will eventually receive protocol unit sent by peer on the other side

  • Layering should be seen as a way to simplify the description of a protocol by decomposing it

    • Does not need to be implemented, although very often it is

      • Because it also simplifies the implementation, V&V, test, etc.

INF6001 Chap 1


Chapitre 1

Some layers can be skipped in certain cases

  • Layer n+2

  • Layer n+1

  • Layer n

  • Sometimes a layer is allowed to use directly services from two layers below.

  • This is done in order to simplify the description: clearly, in the example above, layer n+1 would have to be more complicated if it couldn’t be skipped.

INF6001 Chap 1


Comment choisir les couches

Comment choisir les couches?

  • Plusieurs critères de génie logiciel peuvent nous aider à trouver une bonne façon de décomposer un protocole complexe en couches

  • Du point de vue de la vérification, le critère le plus important est que les interfaces de service puissent être décrite de façon beaucoup plus simple que la somme des protocoles sous-jacents

    • Exemples à suivre

  • Ceci est d’ailleurs un principe commun en génie

    • P. ex. la spécification du service d’une pile électrique peut inclure le voltage et les dimensions

      • Pas normalement le fonctionnement interne: alcaline, NiCa, etc…

    • Le service offert par une couche d’isolation thermique peut être décrit en termes de RXX, le coefficient d’isolation,sans devoir dire quelle est la structure interne de la couche (fibre de verre, mousse…)

INF6001 Chap 1


Couches osi

Couches OSI

Réf:

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

INF6001 Chap 1


Mod le de r f rence open systems interconnection

Modèle de référence Open Systems Interconnection

INF6001 Chap 1


Fonctionnement global

Fonctionnement Global

INF6001 Chap 1


Chapitre 1

OSI Lower Layers

  • Physical. Responsible for the actual transmission of bits over a physical medium (but the physical medium itself is below the physical layer).

  • Data Link. Responsible for the accurate transmission of data between two adjacent systems: error detection and correction, data sequencing.

  • Network. Addressing and routing. Responsible for data delivery to the final destination.

  • Transport. Responsible for reliable end-to-end data transmission. Creates and removes packets, i.e. the transport layer will take a byte stream (a logical message) from a session entity, packetize it for transmission by the network layer, and de-packetize it for delivery of a byte stream to a session entity.

INF6001 Chap 1


Chapitre 1

but-à-but

transport layer

transport layer

netwk layer

netwk layer

network layer

network layer

data link layer

data link layer

data link layer

data link layer

physical layer

physical layer

physical layer

physical layer

liens adjacents

OSI: Different scope of coverage by layers 1,2,3 and layer 4 and above

INF6001 Chap 1


Couche transport

Couche Transport

Correspond à la couche TCP dans TCP/IP

  • Trois fonctionnalités de base:

    • Transforme les paquets en chaînes d’octets

      • Masque la paquetage aux couches supérieures

      • En dessus du transport, on ne considère plus les erreurs de transmission paquets

    • Ignore les relais intermédiaires

      • But à but, End-to-end

    • La couche transport est donc un pivot essentiel dans une pile de protocoles

INF6001 Chap 1


Chapitre 1

OSI Higher Layers

  • Session. It keeps track of the dialogue between peer entities. The entities can stop and restart the dialogue by agreement or in response to system failures, can make periodic checkpoints, etc. (e.g. I am stopping now, will restart later, make sure you know where I’ll restart)

  • Presentation. Responsible for the presentation of data. It negotiates with other layers how the information will be represented. (I will send you MS-Word files, OK? No, I don’t speak MS, can you send in PDF? Etc.)

  • Application. This layer provides facilities that are used directly by applications. E.g., directory services, remote procedure call, transaction control.

INF6001 Chap 1


Entit s osi

Entités OSI

N+1-Protocol Entity

N+1-Protocol Entity

N+1-PDUs

N-SDUs

N-SDUs

N-SAP

N-SAP

N-Service Provider

SAP: Service Access Point

INF6001 Chap 1


Entit s et unit de donn es osi

Entités et unité de données OSI

N+1Protocol Entity

N+1Protocol Entity

N+1 PDUs

N-SDUs

N-SDUs

N Protocol Entity

N Protocol Entity

N PDUs

N-1 SDUs

N-1 SDUs

N-1 Service Provider

N Service Provider

INF6001 Chap 1


Service data units sdus

Service Data Units (SDUs)

  • Request : Une entité sollicite un service

  • Indication : Une entité est informée d'une demande de service

  • Response : Une entité a rendu le service, si possible

  • Confirmation : Une entité est informée que le service a été rendu

SAP

SAP

Service

non confirmé

REQUEST

INDICATION

Service

confirmé

CONFIRMATION

RESPONSE

INF6001 Chap 1


Cas d usage dans la couche transport osi

Cas d’usage dans la couche transport OSI

INF6001 Chap 1


Exemple service de la couche transport osi cas d usage

Exemple: Service de la couche Transport OSICas d’usage

B

B

A

A

T-ConReq

T-ConConf

T-ConReq

T-DiscInd

T-ConInd

T-ConResp

T-ConInd

T-DiscReq

Connexion avec Succès AB

Connexion refusée par B

B

B

A

A

T-ConReq

T-DatReq

T-DatInd

T-DiscInd

Tentative de connexion de A refusée par le fourniss. de service

Transfert Données

AB

A et B sont les SAPs des entités de protocoles A et B

INF6001 Chap 1


Service couche transport d connection cas d usage

Service couche transport: déconnectionCas d’usage

B

A

B

A

T-DiscReq

T-DiscReq

T-DiscReq

T-DiscInd

Les deux décident

de déconnecter

(collision)

A décide de

déconnecter

B

A

T-DiscInd

T-DiscInd

Il y en a quelques autres…

Le fournisseur de

Service décide de

déconnecter

INF6001 Chap 1


Service transport change typique

Service Transport: Échange typique

(Nouvelle connexion)

(Notes de cours du Prof. Bochmann, Ud’Ottawa)

INF6001 Chap 1


Two way handshake

Two-way handshake

  • Note that only two messages are sufficient in order to establish connection

  • This is because TS assumes that the underlying services are ‘perfect’, this means that all messages are (eventually) delivered

    • So a last message from initiator back to responder is unnecessary

    • In fact, this fact also determines other aspects of this SDU exchange

INF6001 Chap 1


D composition et fonctionnement de la couche transport osi

Décomposition et fonctionnementde la couche Transport OSI

INF6001 Chap 1


Protocoles et interfaces

Protocoles et interfaces

SAP N

Protocole Couche N

Interface

entre couche N et couche N-1

SAP N-1

  • Il y a une interface logique entre la couche N et la couche N-1

Couche N

décomposée

INF6001 Chap 1


Fonctionnement de protocoles et interfaces

Fonctionnement de protocoles et interfaces

  • Le protocole de couche N génère et répond aux unités de service (SDUs)

    • allant au

    • provenant de SAP N

  • Il génère et répond aussi aux unités de protocoles (PDUs)

    • allant au

    • provenant de l’interface avec SAP N-1

  • L’interface: encapsuler, décapsuler

    • Prend les unités de protocoles (PDUs) générées par le protocole N et les encapsule pour former des unités de service(SDUs) dirigées au SAP N-1

    • Prend les unités de service générées (SDUs) par le protocole N-1 et les décapsule pour générer des unités de protocole (PDUs) dirigées au protocole N

INF6001 Chap 1


La couche transport osi et ses unit s de donn es pour la phase connexion

La couche transport OSI et ses unités de données pour la phase connexion

Unités service couche transport:

Ce schéma s’applique à toutes les couches

T-SAP

T-ConReq, T-ConResp,

T-ConInd, T-ConConf

Protocole Couche T

CR, CC

Interface

Avec couche réseau:

Encapsulation, décapsulation

Unités de service couche Réseau

N-SAP

N=Network=Réseau

CR et CC sont les PDUs: ils sonttransmis vers ou des couches inférieures encapsulés dans N-DatReq¸ N-DatInd, p.ex. N-DatReq(CR, …)

INF6001 Chap 1


Id alement la transmission des pdu est directe

Idéalement, la transmission des PDU est directe

T-ConReq

T-ConInd

T-SAP

T-SAP

CR

Protocole

Transport

Protocole

Transport

INF6001 Chap 1


En r alit elle passe travers le service sous jacent

En réalité, elle passe à travers le service sous-jacent

T-ConReq

T-ConInd

T-SAP

T-SAP

Protocole

Transport

Protocole

Transport

CR

CR

décapsulation

encapsulation

Interface

Interface

N-DatReq(CR,…)

N-DatReq(CR,…)

N-SAP

N-SAP

Service Réseau (Network)

Observez comment les primitives d’un protocole (CR dans ce cas) sont transmis comme données au niveau sous-jacent et puis récupérés

INF6001 Chap 1


Au d but

Au début …

  • Le fait qu’un CR de transport est transféré comme donnée par la couche réseau suppose qu’il y a déjà une connexion à la couche réseau …

  • Comment faire si elle n’existe pas?

  • Il y a un mécanisme pour traiter ce cas:

    • Le protocole transport peut créer une connexion réseau en invoquant directement une N-ConReq (au lieu de passer un CR)

      • Détail technique sur lequel je n’insisterai pas

INF6001 Chap 1


Connexion r seau

Connexion Réseau

  • Dans la couche Transport, nous pouvons avoir plusieurs connexions

  • Les demandes de connexion Transport sont normalement reliées à la couche Réseau encapsuléescomme données comme suit:

    N-DatReq(CR(params), params)

    • Les params ajoutés dans l’encapsulation sont spécifiés dans les détails du protocole

INF6001 Chap 1


Unit s trait es par le protocole transport phase connexion simplifi

Unités traitées par le protocole transport, phase connexion (simplifié)

INF6001 Chap 1


Sc nario typique travail de hanene ben yedder 2010

Scénario typique (travail de Hanene Ben Yedder, 2010)

Nouvelle

connexion

INF6001 Chap 1

(Sera plus clair après le prochain chapitre)


Les autres couches

Les autres couches

  • Les autres couches OSI suivent essentiellement les mêmes principes

  • Nous avons utilisé l’exemple de la couche transport car elle est la plus simple et propre

INF6001 Chap 1


D composition et recomposition de sdus et pdus entre couches

Décomposition et recomposition de SDUs et PDUs entre couches

INF6001 Chap 1


R lation entre sdu et pdu

Rélation entre SDU et PDU

  • Dans le cas le plus simple, une couche transmet les données telles quelles à la couche adjacente, après avoir ajouté ou enlevé ses propres informations.

  • Mais souvent nous avons:

    • Segmentation/réassemblage

    • Groupage/dégroupage

    • Concaténation/séparation

INF6001 Chap 1


Pourquoi segmentation groupage etc

Pourquoi segmentation, groupage, etc.

  • Les entités de données doivent être organisées selon les besoins des protocoles dans les différentes couches

  • P.ex. dans les premières 3 couches, il est pratique d’avoir des courtes unités d’information (paquets, trames…) car les protocoles se préoccupent de

    • Détection et correction d’erreurs: pour pouvoir localiser l’erreur et au besoin retransmettre seulement l’information qui a été touchée par l’erreur

    • Multiplexage des canaux: plusieurs connexions partagent les canaux, donc on le donne à chaque connexion pour un court instant seulement

  • Après la couche transport, il est plus convenable de travailler avec des unités d’information qui ont une signification logique

    • La couche transport elle même transmet aux niveaux supérieurs des chaînes d’octets de longueur arbitraire, mais ayant une valeur logique

      • Une commande de transaction, un message électronique, une interrogation SQL…

INF6001 Chap 1


Encapsulation simple

Encapsulation simple

PCI: Protocol Control Info

(source des figures :

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

INF6001 Chap 1


Segmentation r assemblage

Segmentation/réassemblage

  • Fonction d'une couche(N) mettant en correspondance une SDU(N) avec plusieurs PDU(N)

    • Adaptation de la taille des données (N-SDU) aux caractéristiques de transmission (N-PDU)

    • Problème : identification des PDU transportant les données constituant la SDU.

    • Exemple : Couche Transport qui rassemble les paquets pour en faire des entités logiques

INF6001 Chap 1

PCI: Protocol Control Info


Groupage d groupage

Groupage/dégroupage

  • Fonction d'une couche(N) mettant en correspondance plusieurs SDU(N) avec une seule PDU(N)

    • Adaptation de la taille des données (N-SDU) aux caractéristiques de la transmission (N-PDU)

    • Diminution du surcoût (overhead)

    • Problème : identification des SDU transportées.

    • Exemple : le tamponnage (bufferisation) des données sous TCP

INF6001 Chap 1


Concat nation s paration

Concaténation/séparation

  • Fonction d'une couche (N) mettant en correspondance plusieurs PDU(N) avec une seule SDU(N)

    • Adaptation de la taille des données aux caractéristiques du service (N-SDU)

    • Diminution du surcoût (overhead)

    • Problème : identification des PDU transportées

    • Exemple : La couche Session qui subdivise des longues interactions en sessions

INF6001 Chap 1


Modes non connect et connect deux principes diff rents de fonctionnement de protocoles

Modes non-connecté et connectéDeux principes différents de fonctionnement de protocoles

INF6001 Chap 1


Mode connect connection oriented

Mode Connecté (connection-oriented)

  • 3 phases :

    • phase d'établissement de la connexion

    • phase de transfert de données

    • phase de libération de la connexion

  • un contexte (réparti) est partagé par les membres de la connexion :

    • par exemple : le numéro du paquet

  • permet (facilite) le contrôle et la gestion du transfert de données :

    • contrôle d'erreur, contrôle de flux, maintien en séquence, etc.

  • les messages échangés comportent des informations qui ne sont utilisables que grâce à la connaissance de ce contexte :

    • par exemple : le numéro de paquet / la largeur de la fenêtre coulissante

  • Exemple de protocole utilisant le mode connecté:TCP

INF6001 Chap 1


Mode non connect connectionless

Mode non connecté (connectionless)

  • 1 seule phase:

    • le transfert de données

  • chaque unité de transfert de données est acheminée indépendamment

  • les entités communicantes ne mémorisent rien ("memoryless").

  • les messages échangées sont auto-suffisants ("self-content")

  • pas d’acquittement de messages (no ack)

  • exemple: datagrammes en IP

INF6001 Chap 1


Chapitre 1

Comparaison

  • Le mode non connecté est beaucoup plus simple à programmer et gérer, il est beaucoup plus efficace.

  • Il laisse beaucoup de responsabilités aux couches supérieures et à l’usager

  • Sur mediums très fiables (p.ex. Fibres optiques) avec commutation très efficace, en pratique le mode sans connection peut fournir une QoS très semblable à celle du mode connecté

  • Pour quelques apps, p.ex. multimédia, il n’est pas essentiel que tous les paquets soient reçus

  • Dont la popularité du protocole IP

INF6001 Chap 1


Un peu d histoire osi et internet

Un peu d’histoire: OSI et Internet

INF6001 Chap 1


Osi pass et futur

OSI, passé et futur

  • L’OSI tel quel n’est plus pratique aujourd’hui

    • Étant donné le succès des protocoles basés sur l’IP

  • Cependant, les concepts de l’OSI sont plus sophistiqués que les concepts des protocoles utilisés plus récemment

    • Il y a encore une forte influence de ces concepts sur les nouveaux protocoles

    • Comme nous verrons

INF6001 Chap 1


Chapitre 1

Various success of OSI concepts

  • The lowest layers of OSI pre-existed OSI and were the most successful (X.25=LAP-B, subsequently modified for use in ISDN)

    • However these protocols have lost importance because they emphasize error detection which

      • has now been rendered almost obsolete by very reliable communication links

      • and can be done in part by the application

  • The higher layers of OSI were the least successful.

    • Especially Session and Presentation were thought to be too complex to implement.

    • It was thought to be preferable to leave such functionalities to the application, i.e. end user.

INF6001 Chap 1


Chapitre 1

Various success of OSI concepts(Continued)

  • One of the least successful aspects of OSI seems to have been the connection-oriented approach

    • Each layer starts a connection

    • Each connection keeps data in order

    • Complexity and overhead to do this!

  • IP instead is connectionless: each packet travels on its own

    • At the higher layer, if the the user requires a connection, it will use TCP to reorder messages.

    • Otherwise UDP (User Datagram Protocol) will be used and the responsibility of reordering messages and detecting missing messages is left to the application.

INF6001 Chap 1


Various success of osi concepts continued

Various success of OSI concepts(Continued)

  • So, what is left of OSI?

    • The idea of protocol layering remains very important and all complex protocols today are layered

      • The notion of service has been transformed into the notion of

        • Protocol interoperability

  • The names of the layers are still used to understand the place of a protocol

    • We still talk of protocols at the transport, application, etc. layer

  • Several OSI Application Layer concepts were found to be useful (Middleware!) and are important in service engineering

    • P. ex. Protocols for Remote Procedure Call

INF6001 Chap 1


Mod le couche en osi et en tcp ip

Modèle à couche en OSI et en TCP/IP

  • Le modèle à couche de l’OSI est utilisé dans TCP/IP

  • Mais les couches Présentation et Session sont absentes (laissées à l’application d’usager)

  • Aussi, tandis que le modèle OSI met l’accent sur les deux concepts de service et protocole

    • La description du service étant souvent beaucoup plus simple que la description des protocoles sous-jacents

  • Le modèle TCP/IP met l’accent sur le concept de protocole

    • Les services et les primitives de services ne sont pas précisément décrits en TCP/IP

    • Il y a seulement le concept d’unités de protocoles qui peuvent être encapsulées et passés aux couches inférieures

    • Tandis que en OSI la déf du modèle a précédé la déf du protocole, pour TCP/IP c’est le contraire

INF6001 Chap 1


Chapitre 1

A bit of history

  • TCP/IP was developed for use by the USA military starting in the late 60s and 70s (ARPANET).

  • X.25 (the lowest 3 layers of OSI) were developed by the CCITT (now ITU-T) in the seventies. It was widely implemented, esp. in Europe.

  • OSI was an effort to extend X.25. It ended up being quite complex.

  • In the late nineties, OSI was abandoned and there was a return to TCP/IP.

INF6001 Chap 1


Osi protocols and internet protocols methodological aspects

OSI Protocols and Internet Protocols:Methodological aspects

  • Internet Protocols are constructed by a very pragmatic approach

  • Protocols are simple, the concepts are simple

  • Much research on protocol engineering was done at the time of OSI and is still valid

  • There is lack of Software Engineering concepts in IP

  • Concepts such as:

    • Formal specification and verification, conformance testing

      • are absent from IP

    • If you want to develop a new implementation, just copy it from an existing one and make sure that it does the same thing ...

  • IP is evolving and is adopting and adapting OSI concepts

    • Nous verrons ceci dans la dernière partie du cours

  • Donc il vaut la peine de les connaître...

INF6001 Chap 1


La notion de service ou d interop rabilit

La notion de service ou d’interopérabilité…

?

Quel est le service fourni par chaque entité?

Quelle est son interface?

INF6001 Chap 1


Une bonne r f rence

Une bonne référence

  • Le manuel classique de Tanenbaum Réseaux contient une bonne discussion de ces points

INF6001 Chap 1


The standards world

The Standards World

INF6001 Chap 1


Chapitre 1

Interconnection and standards

  • Everything in telecom may appear to be easy if one thinks of only one carrier:

    • e.g. internet telephony nowadays is a reality in proprietary systems: all participants must subscribe to the same carrier.

  • However the essence of telecom is several carriers working together to provide a set of commonly understood services.

    • Services are programmed independently by different carriers

    • Externally, they must behave in the same way

    • They may have to interact with related services provided by other carriers

      • commonly understood protocols

INF6001 Chap 1


Chapitre 1

Standard bodies

  • The most important standard body in telecom is the ITU-T.

    • International Telecommunications Union, an agency of the United Nations. See http://www.itu.int/

    • The -T stands for Telecom Standardization Sector

    • -R stands for radio

  • Also influential: ISO

    • International Organization for Standardization, also agency of the UN

    • But ISO has now withdrawn from telecom sector

  • In North America: ANSI

    • American National Standards Institute

  • Many others:

    • TIA: Telecom Industry Association

    • ETSI: European Telecom Standards Institute

    • ATM Forum

    • IETF for Internet...

INF6001 Chap 1


Chapitre 1

How Standard Bodies Work(there is a variety of procedures)

  • Consensus process

  • Voluntary process, driven by government regulators and industries

  • Typical operation (ISO, ITU):

    • Member bodies are countries (Canada, USA, UK, France...). (In other cases, they can be companies, etc.)

    • Member bodies have own standards councils (e.g. Standards Council of Canada http://www.scc.ca/), participants are interested individuals (the experts), often delegated by companies.

    • Member bodies propose Work Items (something that needs to be standardized)

    • Work item is approved by international ballot

    • A committee is formed, made of interested experts from several countries

INF6001 Chap 1


Chapitre 1

Typical operation (ISO, ITU)(Continued . . .)

  • The committee meets many times and works on progressively more complete working drafts

  • Each draft is submitted for ballot to member bodies. Each body decides on the vote (yes, no, abstain). Votes include technical comments for enhancements, etc.

  • The final approveddocument is called a standard or recommendation.

  • Standard and recommendations are then maintained and periodically enhanced by appropriate committees, again each change must be discussed and approved.

INF6001 Chap 1


Chapitre 1

What are standards based on

  • Some standards simply document preexisting industrial practices, regulations, or ‘de facto’ standards (e.g., metric).

    • However these are usually modified during the standardization process, trying to make them more complete and more consistent

  • Other standards attempt to combine existing practices and regulations, usually trying to establish a compromise

    • different practices may become different ‘options’

  • Some standards are created in the standardization bodies in order to respond to some needs (much of the Open Systems Interconnection was like this).

INF6001 Chap 1


Chapitre 1

Who participates in the standardization process

  • This varies very much, according to the type of standard and of standard organization.

  • In the past,

    • ISO and ANSI standards were mostly driven by industrial concerns

    • ITU standards were mostly driven by government regulatory bodies in telecom

      • in Europe, the PTTs (Post, Telephone, Telegraph ministries)

      • in NA, large companies having dominance in some areas

  • Other standard bodies are organized by professional associations, for example electrical engineers in the case of the IEEE.

  • De-regulation is giving more importance to the real implementers and users, this means the industries.

INF6001 Chap 1


Chapitre 1

De-regulation

  • The telecom industry used to be heavily regulated by governments.

  • Governments (PTTs) were the carriers, they set the standards, and they implemented and used them.

    • Users, other companies had almost no say

  • International agreements have opened the field. Effect:

    • Governments have only minimal regulatory say. For example, they regulate the use of transmission frequencies and they auction them.

      • They are still useful as mediators.

    • Companies can offer telecom services to individuals.

    • Large telecom R&D agencies associated with governments have had to become commercial (p.ex. France Telecom).

INF6001 Chap 1


Chapitre 1

The varying value of standards

  • In the past, the main players in telecom were governments and associated companies.

  • ITU recommendations were agreed on among them and were like laws: everyone used them.

  • Standardization process was slow. It took years to complete a standard.

  • De-regulation has created a more fluid situation. If a group of companies that is sufficiently strong agrees on some system architecture, that one can become like a standard among these companies. Others can also join.

    • many such groups exist, and are dynamically reconfiguring themselves

  • It happens now that standards created by official standardization bodies are not getting used, while other rules that are not official standards attain wide use.

  • ITU, ISO, etc. are starting to try and ‘catch up’ by speeding the standardization process and enabling fast standardization of existing industrial practices.

INF6001 Chap 1


Chapitre 1

De facto standards

  • De facto = Latin for: in actual fact, though not perhaps justly or according to law (Longman’s dictionary) (opposite is de jure)

  • These are generally recognized rules, which are not standards of any standards body.

    • Internet (TCP/IP), the WWW were at the beginning de facto standards

    • UNIX, Windows in the operating systems also were de-facto

      • Now they are being regulated, standardized

  • De facto standards are quite strong, because they have survived on their own only because of user satisfaction.

  • Often they become official standards when some standard body becomes interested in them.

  • They may be popular variations of existing standards

INF6001 Chap 1


Chapitre 1

Current situation

  • Companies work hard to provide increasingly complex systems at lower costs.

  • Users shift allegiances quickly to find companies that offer more for less.

  • There are lots of different standards, and variations of standards.

  • High quality of telecom services was expected in the past situation of strict government regulation and monopoly.

  • This quality may decline in the short run, to test how bad (and inexpensive) it can get before customers stop buying a product.

  • De facto standards may become dominant.

INF6001 Chap 1


Chapitre 1

Standards and Implementation

  • Standards usually contain architectural information

    • i.e. they decompose the system in parts and specify internal protocols between the parts

  • it is important to understand that such decomposition has no normative value.

    • implementor is free to decompose the system in another way and to have different internal protocols

    • as long as the externally observable behavior of the system is as specified

    • in other words, the system is a black box and the internal decomposition is only for description purposes

    • the decomposition and protocol specified in the standard can be very inefficient to implement, this does not matter.

INF6001 Chap 1


Chapitre 1

A standard defines a Black Box

The way it is described (yellow)

does not have to be the way it is implemented (green)

But description and implementation must look the same at the interfaces (red)

INF6001 Chap 1


Histoire de l ing nierie des protocoles

Histoire de l’ingénierie des protocoles

  • Les premiers protocoles étaient le produit exclusif de compagnies ou autres organisations

  • L’adoption d’un protocole se faisait en achetant et installant une implantation donnée

  • L’OSI fut un effort de créer des protocoles normalisés et modulaires, pour favoriser la combinaison d’implantations partielles entre compagnies

  • Il fut reconnu (fin 1970) que afin que ceci soit possible, il était nécessaire de pouvoir

    • Spécifier de façon formellement précise les différentes composantes (couches, protocoles)

    • Adopter des précis critères de V&V et de test

INF6001 Chap 1


Histoire de l ing nierie des protocoles ctn

Histoire de l’ingénierie des protocoles (ctn)

  • La plupart de la recherche discutée dans ce cours fut faite dans les années 1980-1995

  • Plus. facteurs on contribué au ralentissement de ce filon de recherches:

    • L’effritement de l’effort OSI et le retour à des protocoles plus simples et déjà bien compris (TCP-IP)

    • La réalisation par les industries que l’utilisation de méthodes rigoureux de développement logiciels est coûteux et lent

      • Peu de considération pour le travail de conception par rapport aux phases finales d’implantation

    • Le coût de développement de logiciels pour bien supporter ce type de méthodes

    • Étant donné qu’un grand nombre de concepts ont déjà été découverts, beaucoup de chercheurs ont passé à autres sujets…

  • Cependant ces techniques retrouveront leur valeur avec l’augmentation de la complexité des applications et un nouvel intérêt pour la qualité du logiciel

INF6001 Chap 1


Concepts importants de ce chapitre

Concepts importants de ce chapitre

  • Niveaux dans la conception et réalisation de logiciel

  • Vérification, validation, test entre niveaux

  • Couches de protocoles

  • La normalisation des protocoles

INF6001 Chap 1


  • Login