3.2.1.2. Receiver Behavior (Comportement du Récepteur) (Remplace Section 8.4.3.2, RFC 8724)

3.2.1.2. Receiver Behavior (Comportement du Récepteur)

Lors de la réception d'un SCHC Fragment avec une paire RuleID et DTag non traitée à ce moment-là:

• le receiver (récepteur) DEVRAIT vérifier que la valeur DTag n'a pas été récemment utilisée pour cette valeur RuleID, garantissant ainsi que le SCHC Fragment reçu n'est pas un vestige d'une transmission de SCHC Packet fragmenté antérieure. La valeur initiale de l'Inactivity Timer (temporisateur d'inactivité) est la durée de vie RECOMMANDÉE pour la valeur DTag au niveau du récepteur. Si le SCHC Fragment est déterminé comme étant un tel vestige, le récepteur PEUT silencieusement l'ignorer et le rejeter.

• le récepteur DOIT démarrer un processus pour assembler un nouveau SCHC Packet avec cette paire de valeurs RuleID et DTag. Le récepteur DOIT démarrer un Inactivity Timer pour cette paire de valeurs RuleID et DTag. Il DOIT initialiser un Attempts counter (compteur de tentatives) à 0 pour cette paire de valeurs RuleID et DTag. Si le récepteur manque de ressources pour le faire, il DOIT répondre à l'émetteur avec un SCHC Receiver-Abort (abandon du récepteur SCHC).

Lors de la réception de tout message SCHC F/R pour la paire RuleID et DTag en cours de traitement, le récepteur DOIT réinitialiser l'Inactivity Timer se rapportant à cette paire RuleID et DTag.

Toutes les réceptions de messages discutées dans le reste de cette section doivent être comprises comme "correspondant à la paire RuleID et DTag en cours de traitement", même si cela n'est pas explicitement indiqué, par souci de concision.

Lors de la réception d'un message SCHC Fragment, le récepteur détermine quelles tiles ont été reçues, en fonction de la longueur de la charge utile et des champs W et FCN du SCHC Fragment.

• si le FCN est All-1 et si une charge utile est présente, la charge utile complète du SCHC Fragment DOIT être assemblée y compris les bits de padding (remplissage). Cela est dû au fait que la taille de la dernière tile n'est pas connue par le récepteur; par conséquent, les bits de padding sont indiscernables des bits de données de tile, à ce stade. Ils seront supprimés par la sous-couche SCHC C/D. Si la taille de la charge utile du SCHC Fragment dépasse ou égale la taille d'une tile régulière plus la taille d'un L2 Word, cela DEVRAIT déclencher un indicateur d'erreur.

• sinon, les tiles DOIVENT être assemblées en fonction de la taille de tile connue a priori.

  • Si autorisé par le Profile, la fin de la charge utile PEUT contenir la dernière tile, qui peut être plus courte. Les bits de padding sont indiscernables des bits de données de tile, à ce stade.

  • La charge utile peut contenir l'avant-dernière tile qui, si autorisé par le Profile, PEUT être exactement d'un L2 Word plus petite que la taille de tile régulière.

  • Sinon, les bits de padding DOIVENT être rejetés. Cela est possible car:

    • la taille des tiles est connue a priori,

    • les tiles sont plus grandes qu'un L2 Word, et

    • les bits de padding sont toujours strictement inférieurs à un L2 Word.

Lors de la réception d'un SCHC All-0 SCHC Fragment:

• si le récepteur connaît des windows avec des tiles manquantes pour le paquet en cours de réassemblage (et en fonction de certains paramètres, comme les conditions du réseau, la taille du tampon/cache de l'émetteur et le délai d'application pris en charge, entre autres), il PEUT renvoyer un SCHC Compound ACK pour les tiles manquantes, en commençant par la window numérotée la plus basse.

Lors de la réception d'un SCHC ACK REQ ou d'un All-1 SCHC Fragment:

• si le récepteur connaît des windows avec des tiles manquantes pour le paquet en cours de réassemblage, il DOIT renvoyer un SCHC Compound ACK pour les tiles manquantes, en commençant par la window numérotée la plus basse.

• sinon:

  • s'il a reçu au moins une tile, il DOIT renvoyer un SCHC Compound ACK pour la window numérotée la plus élevée pour laquelle il possède actuellement des tiles,

  • sinon, il DOIT renvoyer un SCHC Compound ACK pour le window number 0.

Un Profile PEUT spécifier d'autres moments et circonstances auxquels un récepteur envoie un SCHC Compound ACK et sur quelle window le SCHC Compound ACK rapporte dans ces circonstances.

Lors de l'envoi d'un SCHC Compound ACK, le récepteur DOIT augmenter l'Attempts counter.

Après avoir reçu un All-1 SCHC Fragment, un récepteur DOIT vérifier l'intégrité du SCHC Packet réassemblé au moins chaque fois qu'il se prépare à envoyer un SCHC Compound ACK pour la dernière window.

Lors de la réception d'un SCHC Sender-Abort, le récepteur PEUT sortir avec une condition d'erreur.

À l'expiration de l'Inactivity Timer, le récepteur DOIT envoyer un SCHC Receiver-Abort, et il PEUT sortir avec une condition d'erreur.

Lorsque l'Attempts counter dépasse MAX_ACK_REQUESTS, le récepteur DOIT envoyer un SCHC Receiver-Abort, et il PEUT sortir avec une condition d'erreur.

Le réassemblage du SCHC Packet se termine lorsque:

• un Sender-Abort a été reçu,

• l'Inactivity Timer a expiré,

• l'Attempts counter a dépassé MAX_ACK_REQUESTS, ou

• au moins un All-1 SCHC Fragment a été reçu et la vérification d'intégrité du SCHC Packet réassemblé est réussie.

Voir la Figure 44 du RFC 8724 pour l'un des nombreux exemples possibles d'une machine à états finis implémentant un comportement de récepteur obéissant à cette spécification. L'exemple fourni est destiné à correspondre à la machine à états finis de l'émetteur de la Figure 43.