3.2.1.2. Receiver Behavior (Empfänger-Verhalten) (Ersetzt Abschnitt 8.4.3.2, RFC 8724)

3.2.1.2. Receiver Behavior (Empfänger-Verhalten)

Beim Empfang eines SCHC Fragment mit einem RuleID- und DTag-Paar, das zu diesem Zeitpunkt nicht verarbeitet wird:

• SOLLTE der receiver (Empfänger) prüfen, dass der DTag-Wert nicht kürzlich für diesen RuleID-Wert verwendet wurde, wodurch sichergestellt wird, dass das empfangene SCHC Fragment kein Überbleibsel einer vorherigen fragmentierten SCHC Packet-Übertragung ist. Der Anfangswert des Inactivity Timer (Inaktivitätstimers) ist die EMPFOHLENE Lebensdauer für den DTag-Wert beim Empfänger. Wenn festgestellt wird, dass das SCHC Fragment ein solches Überbleibsel ist, KANN der Empfänger es stillschweigend ignorieren und verwerfen.

• MUSS der Empfänger einen Prozess starten, um ein neues SCHC Packet mit diesem RuleID- und DTag-Wertepaar zusammenzusetzen. Der Empfänger MUSS einen Inactivity Timer für dieses RuleID- und DTag-Wertepaar starten. Er MUSS einen Attempts counter (Versuchszähler) für dieses RuleID- und DTag-Wertepaar auf 0 initialisieren. Wenn der Empfänger nicht über ausreichende Ressourcen verfügt, um dies zu tun, MUSS er dem Sender mit einem SCHC Receiver-Abort (SCHC-Empfänger-Abbruch) antworten.

Beim Empfang einer beliebigen SCHC F/R-Nachricht für das RuleID- und DTag-Paar, das verarbeitet wird, MUSS der Empfänger den Inactivity Timer zurücksetzen, der sich auf dieses RuleID- und DTag-Paar bezieht.

Alle Nachrichtenempfänge, die im Rest dieses Abschnitts diskutiert werden, sind als "passend zum verarbeiteten RuleID- und DTag-Paar" zu verstehen, auch wenn dies der Kürze halber nicht ausdrücklich erwähnt wird.

Beim Empfang einer SCHC Fragment-Nachricht bestimmt der Empfänger anhand der Payload-Länge und der W- und FCN-Felder des SCHC Fragment, welche tiles empfangen wurden.

• wenn der FCN All-1 ist und eine Payload vorhanden ist, MUSS die vollständige SCHC Fragment Payload einschließlich der padding bits (Auffüllbits) zusammengesetzt werden. Dies liegt daran, dass die Größe der letzten tile dem Empfänger nicht bekannt ist; daher sind padding bits in diesem Stadium von den tile-Datenbits nicht zu unterscheiden. Sie werden von der SCHC C/D-Unterschicht entfernt. Wenn die Größe der SCHC Fragment Payload die Größe einer regulären tile plus die Größe eines L2 Word überschreitet oder erreicht, SOLLTE dies ein Fehler-Flag auslösen.

• andernfalls MÜSSEN tiles basierend auf der a priori bekannten tile-Größe zusammengesetzt werden.

  • Wenn vom Profile erlaubt, KANN das Ende der Payload die letzte tile enthalten, die kürzer sein kann. padding bits sind in diesem Stadium von den tile-Datenbits nicht zu unterscheiden.

  • Die Payload kann die vorletzte tile enthalten, die, wenn vom Profile erlaubt, genau ein L2 Word kleiner als die reguläre tile-Größe sein KANN.

  • Andernfalls MÜSSEN padding bits verworfen werden. Dies ist möglich, weil:

    • die Größe der tiles a priori bekannt ist,

    • tiles größer als ein L2 Word sind, und

    • padding bits immer strikt kleiner als ein L2 Word sind.

Beim Empfang eines SCHC All-0 SCHC Fragment:

• wenn der Empfänger von windows mit fehlenden tiles für das Paket weiß, das zusammengesetzt wird (und abhängig von bestimmten Parametern wie Netzwerkbedingungen, Sender-Puffer-/Cache-Größe und unterstützter Anwendungsverzögerung, unter anderem), KANN er einen SCHC Compound ACK für die fehlenden tiles zurücksenden, beginnend mit dem niedrigsten nummerierten window.

Beim Empfang eines SCHC ACK REQ oder eines All-1 SCHC Fragment:

• wenn der Empfänger von windows mit fehlenden tiles für das Paket weiß, das zusammengesetzt wird, MUSS er einen SCHC Compound ACK für die fehlenden tiles zurücksenden, beginnend mit dem niedrigsten nummerierten window.

• andernfalls:

  • wenn er mindestens eine tile empfangen hat, MUSS er einen SCHC Compound ACK für das höchstnummerierte window zurücksenden, für das er derzeit tiles hat,

  • andernfalls MUSS er einen SCHC Compound ACK für window number 0 zurücksenden.

Ein Profile KANN andere Zeiten und Umstände spezifizieren, zu denen ein Empfänger einen SCHC Compound ACK sendet und über welches window der SCHC Compound ACK in diesen Umständen berichtet.

Beim Senden eines SCHC Compound ACK MUSS der Empfänger den Attempts counter erhöhen.

Nach dem Empfang eines All-1 SCHC Fragment MUSS ein Empfänger die Integrität des zusammengesetzten SCHC Packet mindestens jedes Mal überprüfen, wenn er sich darauf vorbereitet, einen SCHC Compound ACK für das letzte window zu senden.

Beim Empfang eines SCHC Sender-Abort KANN der Empfänger mit einer Fehlerbedingung beenden.

Bei Ablauf des Inactivity Timer MUSS der Empfänger einen SCHC Receiver-Abort senden, und er KANN mit einer Fehlerbedingung beenden.

Wenn der Attempts counter MAX_ACK_REQUESTS überschreitet, MUSS der Empfänger einen SCHC Receiver-Abort senden, und er KANN mit einer Fehlerbedingung beenden.

Die Wiederzusammensetzung des SCHC Packet endet, wenn:

• ein Sender-Abort empfangen wurde,

• der Inactivity Timer abgelaufen ist,

• der Attempts counter MAX_ACK_REQUESTS überschritten hat, oder

• mindestens ein All-1 SCHC Fragment empfangen wurde und die Integritätsprüfung des zusammengesetzten SCHC Packet erfolgreich ist.

Siehe Abbildung 44 von RFC 8724 für eines von mehreren möglichen Beispielen einer Finite State Machine (endlichen Zustandsmaschine), die ein dieser Spezifikation gehorchendes Empfänger-Verhalten implementiert. Das bereitgestellte Beispiel soll mit der Sender Finite State Machine von Abbildung 43 übereinstimmen.