Archive 07/10/2020.

Fragmentation dans 6LowPAN - Question 4.3.5

gfoltete

Bonjour,
Je m’étonne que la réponse dans le quizz en ce qui concerne la non réception d’un fragment de paquet IPv6 (dernière question). Je pensais que le champ datagram_offset permettait de connaître le numéro du fragment et donc de ne pas tout renvoyer le paquet.
Merci pour vos éclaircissements

Elouanc

Bonjour,
J’avoue que j’ai le même questionnement.
Est-ce le fait que ce soit de l’UDP principalement qui est utilisé en tant que protocole qui fait qu’il a de nouveau besoin de tout le message car cela entame au final la capacité de transmission s’il y’a beaucoup de conflit lors de la transmission ?

jcw67

Bonjour,

N’ayant pas trouvé de piste dans le cours, j’étais allé voir l’article 6LoWPAN sur Wikipédia.

Dans le paragraphe Fragmentation et ré-assemblage., on parle d’un “mécanisme d’acquittement des fragments”, qui “permet à l’expéditeur de ne retransmettre que les fragments non reçus (non acquittés)” (réf : article de 2010).

Cette proposition est-elle restée à l’état de projet ?

jc

michel_billaud

Pour qu’il y ait retransmission, il faut qu’il y ait un protocole qui demande de retransmettre les morceaux qui manquent.

Apparemment, il y a eu une proposition dans ce sens https://tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-recovery-07 en 2010

This draft introduces a simple protocol to forward and
recover individual fragments that might be lost over multiple hops
between 6LoWPAN endpoints

qui connait des mises à jour (du 18 mars 2020 !) https://tools.ietf.org/html/draft-ietf-6lo-fragment-recovery-17 mais c’est pas fait à ce que j’en comprends.

Dans ce cas, la retransmission sera demandée par les couches du dessus, quand elles s’impatientent de ne pas voir arriver les paquets (reconstitués) attendus.