Mécanismes de fiabilisation pro-actifs - ISAE

32 Chapitre 2. Etat de l'art et principales notionsplace les mécanismes de détection et de reprise sur erreur.Le protocole IPHC se base sur quatre types de paquets : Les paquets FULL_HEADER permettent de transporter l'en-tête non compressé.De manière similaire à CTCP, le champ Packet Length d'IP étant fournipar la couche liaison, celui-ci sert ici au transport du CID et éventuellement dugeneration. Ce type de paquet est utilisé pour un établissement ou un rafraîchissementdu contexte eectué de manière régulière an d'éviter la propagationd'erreurs. Les paquets COMPRESSED_NON_TCP qui se chargent donc de la compressionde l'en-tête IP seul. Dans ce cas, l'en-tête IP est remplacé par deux octetspermettant la transmission du CID et du generation. Les paquets COMPRESSED_TCP qui sont donc les paquets les plus courantsdans ce mécanisme. Ils permettent le transport de l'en-tête compressé TCP/IPà l'aide d'un codage diérentiel, ainsi que l'identiant de contexte. Le schémade cet en-tête est très similaire à celui de CTCP, le bit inutilisé étant remplacépar R, drapeau permettant la dénition d'extensions supplémentaires. Le bit Cde CTCP est ici inutile car le CID est toujours transmis. Les paquets COMPRESSED_TCP_NODELTA qui permettent l'envoi de l'entêteTCP non compressé sans les numéros de port. En accolant le CID, la taillede cet en-tête est de 17 octets. Ce type de paquet ne peut être envoyé qu'enréponse au mécanisme de Header Request détaillé par la suite.L'une des principales nouveautés des protocoles IPHC et CRTP est la mise enplace de mécanismes de abilisation. Deux mesures principales ont été mis en oeuvrean de lutter contre les défauts inhérents au codage diérentiel.Dans un protocole plus classique, tel CTCP, lorsqu'un en-tête est perdu, le décompresseurest incapable de récupérer les paquets suivants, pourtant reçus, jusqu'àréception d'un en-tête non compressé qui contient le nouveau contexte. Dans le butd'éviter ce genre de désynchronisation, IPHC et CRTP implémentent un mécanismeappelé TWICE. L'idée de l'algorithme TWICE est de considérer que lorsque un entêteest reçu, si la somme de contrôle de TCP échoue, alors cet échec est imputableà une perte de paquets. Dans ce cas, le décompresseur va considérer que le ou lespaquets perdus apportaient le même codage diérentiel que celui reçu, et va appliquerce diérentiel une ou plusieurs fois.Lorsque le mécanisme TWICE échoue, IPHC permet de basculer sur le secondmécanisme de reprise sur erreur : Header Request. Le décompresseur a la possibilitéd'envoyer un paquet nommé CONTEXT_STATE. Dans ce paquet, le décompresseurprécise le ou les CID pour lequel le contexte est invalidé. Lorsque le compresseur reçoitcette notication, il utilise alors un paquet COMPRESSED_TCP_NODELTA quicontient l'intégralité de l'en-tête TCP et permet donc de resynchroniser le récepteur.Par la suite, IPHC utilise un mécanisme de reprise sur erreur de type Slow Start, bienconnu de TCP. Initialement chaque en-tête non compressé est séparé par l'envoi d'un