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
Fragmentation dans 6LowPAN - Question 4.3.5


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 ?

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

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.