Docstoc

INF 6001 Chap 1

Document Sample
INF 6001 Chap 1 Powered By Docstoc
					                       Chapitre 1

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



w3.uqo.ca/luigi
                                         1
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                            2
Sujet du cours


 Méthodes de:
     Spécification
     Conception
     Validation
     Vérification
     Test
         De protocoles de communication




INF6001 Chap 1                             3
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
     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 et
  comparaison des résultats avec les exigences

INF6001 Chap 1                                                       4
Spécifications et exigences

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




INF6001 Chap 1                                             5
Différents niveaux de spécif
et cycle de développement
   Spec d’exigences (langue
  naturelle, notation logique)


       Spécification du
        comportement             Nous pouvons effectuer des V&V
                                 et du test entre tous les niveaux
       Spécification de
        l’implantation
  (comportement utilisant des
    composantes données)



         Implantation


INF6001 Chap 1                                                 6
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                                                 7
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:
      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                   Spec d’exigences (langue
                                                              naturelle, notation logique)
 Nombreuses méthodes de spec développés, p.ex.
      Use Cases (UML)                                                 Spécification du
      Use Case Maps                                                   comportement

      Notations logiques (OCL en UML)
                                                                       Spécification de
      Diagrammes de transitions d’états…                               l’implantation
 Il y a tout un domaine de recherches qui s’appelle               (comportement utilisant de
                                                                     composantes données)
      Requirement Engineering
INF6001 Chap 1                                                                      8
                                                                         Implantation
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
                                                                       Spec d’exigences (langue
       le système passe à un état attente                              naturelle, notation logique)
      il passe puis à l’état sonnerie ou signal occupé
 La structure interne de la spec est abstraite, ne                        Spécification du
                                                                           comportement
  correspond pas nécessairement à un modèle
  d’implantation                                                           Spécification de
                                                                            l’implantation
                                                                       (comportement utilisant de
                                                                         composantes données)


INF6001 Chap 1                                                                          9
                                                                             Implantation
   Spec partielle du comportement d’un téléph.

                                            CallAlert
                    OffHook                 StartRinging
                                 Idle
                    DialTone



                     Dialing   OnHook
                               Click          Ringing
DialDIgits
Clicks

                                        OffHook
                                        StopRing
                       Path
                      Active



                                             Notation:     Mess. entrée
                                                           Mess. sortie

   INF6001 Chap 1                                                   10
 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.
                                                       Spec d’exigences (langue
                                                      naturelle, notation logique)
 http://home.swbell.net/mck9/cobol/tech/fsmwtn.html

                                                           Spécification du
                                                            comportement


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



 INF6001 Chap 1                                              Implantation
                                                                              11
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                                                         12
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                                                  13
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                                                     14
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                                                                   15
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                                                              16
Conception et description à couches




INF6001 Chap 1                    17
Conception à couches des protocoles
 Un protocole contient normalement un grand nombre
  de fonctionnalités
 Pourrait être défini comme un seul programme, mais
  ceci serait excessivement complexe
 Le manque de modularité rendrait aussi difficile
  l’échange de modules préfabriqués entre compagnies




INF6001 Chap 1                                         18
Expressivité du concept de service

 3+2 = 5
 Vous pouvez utiliser 5
  pour représenter 3+2




INF6001 Chap 1                       19
Expressivité du concept de service
 3+2 = 5                   Service sous-jacent +
 Vous pouvez utiliser 5     protocole = nouveau
  pour représenter 3+2       service
                            Vous pouvez utiliser le
                             nouveau service pour
                             représenter le
                             service sous-jacent +
                             protocole



INF6001 Chap 1                                         20
Communication entre paires


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                                                     21
    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                                      Service Data Units
      SDUs                                                    SDUs


                           Service Provider



     INF6001 Chap 1                                                          22
   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               PDUs                      Service Data Units

             Assistant A                          Assistant B

Service Data Units                                         Service Data Units


                           Service Provider
   INF6001 Chap 1                                                          23
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                PDUs                     Service Data Units


             Assistant A                          Assistant B

           SDU                                              SDU

             Secretary A                          Secretary B
             SDU                                            SDU

                             Service Provider
INF6001 Chap 1                                                          24
 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                                                 25
 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                                                                           26
 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                                                                         27
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                                                        28
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                                                                29
                     Couches OSI


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




INF6001 Chap 1                                                                               30
Modèle de référence Open Systems
Interconnection




INF6001 Chap 1                     31
Fonctionnement Global




INF6001 Chap 1          32
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                                                               33
transport layer
                                          but-à-but                     transport layer
network layer           netwk layer                    netwk 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                                                                34
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                                                      35
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. For example, directory services,
  remote procedure call, transaction control.
INF6001 Chap 1                                                   36
 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                                                      37
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                                                              38
  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



REQUEST                              INDICATION     Service
                                                    non confirmé
                                                                       Service
                                                                       confirmé
CONFIRMATION                         RESPONSE




  INF6001 Chap 1                                                              39
Cas d’usage dans la couche transport OSI




INF6001 Chap 1                        40
      Exemple: Service de la couche Transport OSI
                                     Cas d’usage
            A        B                                  A       B
T-ConReq                                  T-ConReq
                         T-ConInd                                   T-ConInd
                         T-ConResp                                  T-DiscReq
T-ConConf                                 T-DiscInd

   Connexion avec Succès AB                   Connexion refusée par B



            A    B                                 A        B
T-ConReq                               T-DatReq
                                                                 T-DatInd

T-DiscInd

  Tentative de                               Transfert Données
  connexion de A                             AB
  refusée
  par le fourniss. de service
                                     A et B sont les SAPs des entités
  INF6001 Chap 1                     de protocoles A et B                       41
  Service couche transport: déconnection
                                   Cas d’usage
                                                      A      B
               A      B
                                         T-DiscReq
 T-DiscReq                                                       T-DiscReq
                          T-DiscInd



                                                     Les deux décident
              A décide de
                                                     de déconnecter
              déconnecter
                                                     (collision)

                A     B
  T-DiscInd
                            T-DiscInd


                                              Il y en a des autres…
         Le fournisseur de
         Service décide de
         déconnecter
INF6001 Chap 1                                                           42
Service Transport: Échange typique




INF6001 Chap 1   Notes de cours du Prof. Bochmann
                                                    43
       Décomposition et fonctionnement
          de la couche Transport OSI




INF6001 Chap 1                           44
 Protocoles et interfaces
  Il y a une interface logique entre la couche N et la
   couche N-1
                            SAP N




                      Protocole Couche N

Couche N
décomposée
                            Interface
                  entre couche N et couche N-1



                             SAP N-1

 INF6001 Chap 1                                           45
Fonctionnement de protocoles et interfaces
                                                                                       SAP N

 Le protocole de couche N génère et répond aux unités de service (SDUs)
   allant au                                                                 Protocole Couche N

   provenant de SAP N
 Il génère et répond aussi aux unités de protocoles (PDUs)                        Interface
   allant au                                                            entre couche N et couche N-1

   provenant de l’interface avec SAP N-1
 Dans quelques cas, il peut aussi traiter directement des unités de service SAP N-1
   P.ex. si une couche N trouve qu’il n’y a pas de connexion à travers la couche N-1,
      alors le protocole N peut invoquer directement le service d’ouverture de
      connexion N-1

 L’interface
   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                                                                             46
 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 transmis vers ou des
                                                couches inférieures encapsulés dans
                                                N-DatReq¸ N-DatInd, p.ex.
 INF6001 Chap 1                                 N-DatReq(CR, …)
                                                                                47
Idéalement, la transmission des PDU est
directe


   T-ConReq                      T-ConInd

            T-SAP      CR    T-SAP
           Protocole        Protocole
           Transport        Transport




INF6001 Chap 1                              48
En réalité, elle passe à travers le service
sous-jacent
                  T-ConReq                                         T-ConInd

                           T-SAP                           T-SAP
                          Protocole                       Protocole
                          Transport                       Transport
encapsulation




                                                                                   décapsulation
                         CR                                      CR

                           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                                                           49
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ées comme
  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
 Mais afin que ceci soit possible, il faut qu’il y ait une
  connexion au niveau Réseau…
 C’est pourquoi la 1ère fois le protocole transport doit créer
  une connexion Réseau en invoquant directement une N-
  ConReq
INF6001 Chap 1                                                      50
Pour la première fois
                                             Unités service couche transport:
                                 T-SAP       T-ConReq, T-ConResp,
                                             T-ConInd, T-ConConf


                          Protocole Couche T
N-ConReq
N-ConConf                                      CR, CC
                                Interface
                         Avec couche N: réseau:
                       Encapsulation, décapsulation

                                              Unités de service couche Réseau
                                  N-SAP
            N=Network=Réseau




INF6001 Chap 1                                                              51
  Unités traitées par le protocole transport,
  phase connexion (simplifié)

  T Service Primitives    T Protocol Primitives N Service Primitives
       (T-SDU)                 (T-PDUs)                 (N-SDUs)
T-ConReq                 CR                     N-ConReq, outgoing
incoming                 incoming/outgoing      If N-Connection must be
                                                 established
T-ConInd                                         N-DatReq
outgoing                                         Incoming, outgoing
T-ConResp
incoming
T-ConConf                CC                      N-ConConf, incoming
outgoing                 incoming/outgoing       If N-Connection must be
                                                 established
  INF6001 Chap 1                                                           52
      Décomposition et recomposition
      de SDUs et PDUs entre couches




INF6001 Chap 1                         53
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                                          54
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                                                                      55
   Encapsulation simple




PCI: Protocol Control Info   (source des figures :

                             http://www.irisa.fr/armor/lesmembres/cousin/Enseignement/Rese
   INF6001 Chap 1            aux-generalites/Cours/4-3.htm                         56
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 : le TCP offre à la couche supérieure une chaîne de données qui lui est
       livrée sous forme de datagrammes par la couche IP
      Exemple pareil dans la couche transport OSI




INF6001 Chap 1                                           PCI: Protocol Control Info           57
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 des données sous TCP




INF6001 Chap 1                                                                             58
 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 OSI divise les unités de transport en sessions, qui sont
       les unités de temps que l’usager décide de dédier à une connexion




 INF6001 Chap 1                                                                               59
      Un peu d’histoire: OSI et Internet




INF6001 Chap 1                             60
OSI, passé et futur


 L’OSI est une norme morte en pratique,
     Étant donné le succès des protocoles basés sur l’IP


 Cependant, les concepts de l’OSI sont meilleurs 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                                                    61
  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                                                                  62
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                                                                           63
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                                                               64
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                                              65
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                                                                66
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                                                  67
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                                                              68
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                                                69
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                                                            70
La notion de service ou d’interopérabilité…




                              ?

  Quel est le service fourni par chaque entité?

  Quelle est son interface?

INF6001 Chap 1                                    71
Une bonne référence
 Le manuel classique de Tanenbaum Réseaux contient
  une bonne discussion de ces points




INF6001 Chap 1                                    72
The Standards World



INF6001 Chap 1        73
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                                                                  74
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                                                                     75
  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                                                                                     76
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 approved document 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                                                      77
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                                                           78
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                                                                79
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                                                            80
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                                                                        81
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                                                                82
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                                                   83
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                                                              84
   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                                                           85
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                                                  86
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                                                                                 87
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                                            88

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:5
posted:4/9/2011
language:French
pages:88