Discussion :

[Skyxia]

Bonjour la communauté !

En ce moment en cours, nous étudions la technologie ATM (Asynchronous Transfer Mode).
Nous avons en lien de ressource ce site : http://slideplayer.fr/slide/1310822/

Et, dans ce diaporama (qui est très intéressant en soit) ils comparent ATM avec... un canard..

Voilà deux photos pour que vous puissiez mieux comprendre :

Question :

https://image.noelshack.com/fichiers...reenshot-1.png

Réponse :

https://image.noelshack.com/fichiers...reenshot-2.png

Si vous avez compris la relation entre les modes de transfert du canard et de ATM, pourriez-vous me l'expliquer plus... clairement ?

Merci d'avance !

Cordialement, Skyxia.

[boboss123]

Salut,

Peut-être que ce qu'il veut dire, c'est que comme un canard, l'ATM peut faire plusieurs choses (le canard peut voler, nager, marcher et l'ATM peut transférer de la data, VoiP, Video).
=> Le problème des slides, c'est que pour tout comprendre, il faut aussi les commentaires de l'auteur

[Skyxia]

C'est vrai qu'on peut voir les choses comme ça, ça me paraissait évident mais je cherchais sans doute plus compliqué pour rien
En tout cas merci pour ta réponse, et je suis d'accord qu'avec les commentaires de l'auteur, ça serait mieux..

Je laisse encore jusque ce soir pour passer en résolu au cas où d'autres personnes ont une vision des choses différentes de celle qu'on a

[Invité]

Dans les années 1995, l'ATM était surnommé le "duck of networking" pour les raisons suivantes :
- un canard sait nager, voler et marcher, so far so good...
- en revanche, il ne marche pas terrible, la nage n'est pas non plus son fort mais il vole très vite.

La métaphore est la suivante : l'ATM sait transporter en théorie et de façon simultanée la voix, la video et la data mais à un instant t, il fait certaines de ces 3 choses mieux que les autres. C'est relatif aux problématiques de end-to-end QoS de réseaux qui s'appuyaient sur des couches basses ATM. Il faut comprendre qu'à cette époque, on n'avait pas de mécanismes normalisés (comme DiffServ/CoS) permettant un queueing adaptatif le long du transit physique. il fallait donc, et en permanence :
- mesurer et monitorer de façon locale et macroscopique la QoS,
- agir sur ces flux en temps réel afin de corriger les déviations...

C'est d'ailleurs ATM qui a donné naissance à des protocoles comme RMON (ou RMON2, je sais plus).
Et c'est après qu'on a commencé à utiliser les champs ToS des en-têtes IP pour les associer à des priority queues différentes, objet de la RFC2475 (en 1998). Elle a été pondue par des boîtes comme Lucent, Nortel, Torrent Technologies qui dominaient à l'époque le marché ATM.

-VX