19. Frame-Typen und -Formate

Wie in Abschnitt 12.4 beschrieben, enthalten Pakete einen oder mehrere Frames. Dieser Abschnitt beschreibt das Format und die Semantik der Kern-QUIC-Frame-Typen.

19.1 PADDING-Frames

Ein PADDING-Frame (type=0x00) hat keinen semantischen Wert. PADDING-Frames können verwendet werden, um die Größe eines Pakets zu erhöhen. Padding kann verwendet werden, um ein Initial-Paket auf die erforderliche Mindestgröße zu erhöhen oder um Schutz gegen Traffic-Analyse für geschützte Pakete zu bieten.

19.2 PING-Frames

Endpunkte können PING-Frames (type=0x01) verwenden, um zu überprüfen, ob ihre Peers noch am Leben sind, oder um die Erreichbarkeit des Peers zu überprüfen. Der PING-Frame enthält keine zusätzlichen Felder.

19.3 ACK-Frames

Empfänger senden ACK-Frames (Typen 0x02 und 0x03), um Sender über Pakete zu informieren, die sie empfangen und verarbeitet haben. Der ACK-Frame enthält einen oder mehrere ACK-Bereiche. ACK-Bereiche identifizieren bestätigte Pakete.

19.3.1 ACK-Bereiche

Jeder ACK-Bereich besteht aus alternierenden Gap- und ACK Range Length-Werten in absteigender Paketnummer-Reihenfolge.

19.3.2 ECN-Zählungen

Der ACK-Frame verwendet das niedrigstwertige Bit (d.h. Typ 0x03), um ECN-Feedback anzuzeigen und den Empfang von QUIC-Paketen mit zugehörigen ECN-Codepunkten von ECT(0), ECT(1) oder CE im IP-Header des Pakets zu melden.

19.4 RESET_STREAM-Frames

Ein Endpunkt verwendet einen RESET_STREAM-Frame (type=0x04), um den sendenden Teil eines Streams abrupt zu beenden.

19.5 STOP_SENDING-Frames

Ein Endpunkt verwendet einen STOP_SENDING-Frame (type=0x05), um mitzuteilen, dass eingehende Daten bei Empfang gemäß Anwendungsanforderung verworfen werden.

19.6 CRYPTO-Frames

Ein CRYPTO-Frame (type=0x06) wird verwendet, um kryptografische Handshake-Nachrichten zu übertragen. Es kann in allen Pakettypen außer 0-RTT gesendet werden.

19.7 NEW_TOKEN-Frames

Ein Server sendet einen NEW_TOKEN-Frame (type=0x07), um dem Client ein Token bereitzustellen, das im Header eines Initial-Pakets für eine zukünftige Verbindung gesendet werden soll.

19.8 STREAM-Frames

STREAM-Frames erstellen implizit einen Stream und tragen Stream-Daten. Der STREAM-Frame nimmt die Form 0b00001XXX (oder die Menge von Werten von 0x08 bis 0x0f) an.

19.9 MAX_DATA-Frames

Ein MAX_DATA-Frame (type=0x10) wird in der Flusskontrolle verwendet, um den Peer über die maximale Datenmenge zu informieren, die insgesamt auf der Verbindung gesendet werden kann.

19.10 MAX_STREAM_DATA-Frames

Ein MAX_STREAM_DATA-Frame (type=0x11) wird in der Flusskontrolle verwendet, um einen Peer über die maximale Datenmenge zu informieren, die auf einem Stream gesendet werden kann.

19.11 MAX_STREAMS-Frames

Ein MAX_STREAMS-Frame (type=0x12 oder 0x13) informiert den Peer über die kumulative Anzahl von Streams eines bestimmten Typs, die er öffnen darf.

19.12 DATA_BLOCKED-Frames

Ein Sender SOLLTE einen DATA_BLOCKED-Frame (type=0x14) senden, wenn er Daten senden möchte, aber aufgrund von Flusskontrolle auf Verbindungsebene nicht dazu in der Lage ist.

19.13 STREAM_DATA_BLOCKED-Frames

Ein Sender SOLLTE einen STREAM_DATA_BLOCKED-Frame (type=0x15) senden, wenn er Daten senden möchte, aber aufgrund von Flusskontrolle auf Stream-Ebene nicht dazu in der Lage ist.

19.14 STREAMS_BLOCKED-Frames

Ein Sender SOLLTE einen STREAMS_BLOCKED-Frame (type=0x16 oder 0x17) senden, wenn er einen Stream öffnen möchte, aber aufgrund des vom Peer gesetzten maximalen Stream-Limits nicht dazu in der Lage ist.

19.15 NEW_CONNECTION_ID-Frames

Ein Endpunkt sendet einen NEW_CONNECTION_ID-Frame (type=0x18), um seinem Peer alternative Verbindungs-IDs bereitzustellen, die verwendet werden können, um die Verknüpfbarkeit bei der Migration von Verbindungen zu brechen.

19.16 RETIRE_CONNECTION_ID-Frames

Ein Endpunkt sendet einen RETIRE_CONNECTION_ID-Frame (type=0x19), um anzuzeigen, dass es eine Verbindungs-ID, die von seinem Peer ausgestellt wurde, nicht mehr verwenden wird.

19.17 PATH_CHALLENGE-Frames

Endpunkte können PATH_CHALLENGE-Frames (type=0x1a) verwenden, um die Erreichbarkeit des Peers zu überprüfen und zur Pfadvalidierung während der Verbindungsmigration.

19.18 PATH_RESPONSE-Frames

Ein PATH_RESPONSE-Frame (type=0x1b) wird als Antwort auf einen PATH_CHALLENGE-Frame gesendet.

19.19 CONNECTION_CLOSE-Frames

Ein Endpunkt sendet einen CONNECTION_CLOSE-Frame (type=0x1c oder 0x1d), um seinen Peer zu benachrichtigen, dass die Verbindung geschlossen wird. Der CONNECTION_CLOSE-Frame mit einem Typ von 0x1c wird verwendet, um Fehler auf der QUIC-Schicht oder das Fehlen von Fehlern zu signalisieren. Der CONNECTION_CLOSE-Frame mit einem Typ von 0x1d wird verwendet, um einen Fehler mit der Anwendung zu signalisieren, die QUIC verwendet.

19.20 HANDSHAKE_DONE-Frames

Der Server verwendet einen HANDSHAKE_DONE-Frame (type=0x1e), um die Bestätigung des Handshakes an den Client zu signalisieren.

19.21 Erweiterungs-Frames

QUIC-Frames verwenden keine selbstbeschreibende Codierung. Ein Endpunkt muss daher die Syntax aller Frames verstehen, bevor es ein Paket erfolgreich verarbeiten kann. Dies ermöglicht eine effiziente Codierung von Frames, bedeutet aber, dass ein Endpunkt keinen Frame eines Typs senden kann, der seinem Peer unbekannt ist.

Eine Erweiterung von QUIC, die einen neuen Frame-Typ verwenden möchte, MUSS zunächst sicherstellen, dass ein Peer in der Lage ist, den Frame zu verstehen. Ein Endpunkt kann einen Transportparameter verwenden, um seine Bereitschaft zu signalisieren, Erweiterungs-Frame-Typen zu empfangen.