Discussion :

[MR-SMOOT]

bonjour,
pourquoi le ospf n'utilise pas protocole tcp/ip et merci.

[TiranusKBX]

d'après http://fr.wikipedia.org/wiki/Open_Shortest_Path_First il utilise des paquets ip même si très limité

[MR-SMOOT]

d'après http://fr.wikipedia.org/wiki/Open_Shortest_Path_First il utilise des paquets ip même si très limité

merci moi je pense que c'est parce que tcp ne support pas le multicast et udp n'est pas fiable et merci pour ton aide

[Invité]

merci moi je pense que c'est parce que tcp ne support pas le multicast

Non, rien à voir. Ne mélanges pas tout.

OSPF est encapsulé dans IP (Protocol Number 89).
On n'a pas utilisé TCP pour transporter les données entre routeurs OSPF parce que ça aurait été trop lourd pour des routeurs d'entreprise.
On a donc préféré qu'OSPF embarque ses propres mécanismes de contrôle de flux. Il y a des acquittements et éventuellement des retransmissions comme en mode connecté TCP (notamment lors de la phase de Database Description lorsque les routeurs sont en train de monter leur adjacence).
Il faut également comprendre qu'un protocole de routage comme OSPF, ça doit être capable de gérer des événements brusques (changements de topologie) pour le recalcul de la table de routage. Ca doit donc être simple, efficace avec un minimum de contrôle de flux. Ce qui le cas d'UDP également, utilisé pour transporter les messages RIP entre routeurs.

Ca n'a pas empêché non plus d'utiliser TCP dans le routage de l'Internet.
En effet, le protocole BGP s'appuie sur TCP (port 179).
Potentiellement, un routeur BGP est dimensionné pour recevoir la table de routage de l'Internet (550000 préfixes IPv4), ça a donc beaucoup de mémoire et une bonne CPU. Donc c'est suffisamment robuste pour pouvoir embarquer quelque chose qui peut tourner au-dessus de TCP.

Steph

[MR-SMOOT]

Non, rien à voir. Ne mélanges pas tout.

OSPF est encapsulé dans IP (Protocol Number 89).
On n'a pas utilisé TCP pour transporter les données entre routeurs OSPF parce que ça aurait été trop lourd pour des routeurs d'entreprise.
On a donc préféré qu'OSPF embarque ses propres mécanismes de contrôle de flux. Il y a des acquittements et éventuellement des retransmissions comme en mode connecté TCP (notamment lors de la phase de Database Description lorsque les routeurs sont en train de monter leur adjacence).
Il faut également comprendre qu'un protocole de routage comme OSPF, ça doit être capable de gérer des événements brusques (changements de topologie) pour le recalcul de la table de routage. Ca doit donc être simple, efficace avec un minimum de contrôle de flux. Ce qui le cas d'UDP également, utilisé pour transporter les messages RIP entre routeurs.

Ca n'a pas empêché non plus d'utiliser TCP dans le routage de l'Internet.
En effet, le protocole BGP s'appuie sur TCP (port 179).
Potentiellement, un routeur BGP est dimensionné pour recevoir la table de routage de l'Internet (550000 préfixes IPv4), ça a donc beaucoup de mémoire et une bonne CPU. Donc c'est suffisamment robuste pour pouvoir embarquer quelque chose qui peut tourner au-dessus de TCP.

Steph

merci j'ai compris mais j'ai une question esce que tcp support le multicast ?

[elssar]

Non ce n'est pas possible pour du TCP. Tout simplement car le multicast et TCP sont 2 techno fondamentalement opposés. Le mode de fonctionnement de TCP demande un ACK des données, donc les clients doivent répondre. Or le multicast est une techno uniquement faite pour envoyer des données, ce n'est pas fait pour en recevoir. Après j'avais entendu quelques idées de techno un peu bâtardes qui cherchent à mixer du multicast+TCP (techno PGM par exemple). Mais bon ça reste du domaine de l'exotique.

[MR-SMOOT]

Non ce n'est pas possible pour du TCP. Tout simplement car le multicast et TCP sont 2 techno fondamentalement opposés. Le mode de fonctionnement de TCP demande un ACK des données, donc les clients doivent répondre. Or le multicast est une techno uniquement faite pour envoyer des données, ce n'est pas fait pour en recevoir. Après j'avais entendu quelques idées de techno un peu bâtardes qui cherchent à mixer du multicast+TCP (techno PGM par exemple). Mais bon ça reste du domaine de l'exotique.

d'accord merci (y)