Zum Hauptinhalt springen

3.3. SCTP-Chunk-Definitionen (SCTP Chunk Definitions)

Dieser Abschnitt definiert das Format der verschiedenen SCTP-Chunk-Typen.

3.3.1. Nutzlastdaten (Payload Data, DATA) (0)

Das folgende Format MUSS (MUST) für den DATA-Chunk verwendet werden:

     0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0 | Reserved|U|B|E| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Identifier S | Stream Sequence Number n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Protocol Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ User Data (seq n of Stream S) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Reserviert (Reserved): 5 Bits

Sollte auf alle '0' gesetzt und vom Empfänger ignoriert werden.

U-Bit: 1 Bit

Das Ungeordnet-Bit (Unordered). Wenn auf '1' gesetzt, zeigt dies an, dass dies ein ungeordneter DATA-Chunk ist, und diesem DATA-Chunk keine Stream-Sequenznummer zugewiesen ist. Daher MUSS (MUST) der Empfänger das Feld Stream-Sequenznummer ignorieren.

Nach der Wiederzusammensetzung (falls erforderlich) MÜSSEN (MUST) ungeordnete DATA-Chunks vom Empfänger ohne jeden Versuch der Neuordnung an die obere Schicht weitergeleitet werden.

Wenn eine ungeordnete Benutzernachricht fragmentiert ist, MUSS (MUST) jedes Fragment der Nachricht sein U-Bit auf '1' gesetzt haben.

B-Bit: 1 Bit

Das Anfangsfragment-Bit (Beginning fragment bit). Wenn gesetzt, zeigt es das erste Fragment einer Benutzernachricht an.

E-Bit: 1 Bit

Das Endfragment-Bit (Ending fragment bit). Wenn gesetzt, zeigt es das letzte Fragment einer Benutzernachricht an.

Eine nicht fragmentierte Benutzernachricht soll sowohl das B- als auch das E-Bit auf '1' gesetzt haben. Das Setzen sowohl des B- als auch des E-Bits auf '0' zeigt ein mittleres Fragment einer Multi-Fragment-Benutzernachricht an, wie in der folgenden Tabelle zusammengefasst:

            B E                  Beschreibung
============================================================
| 1 0 | Erstes Stück einer fragmentierten Benutzernachricht |
+----------------------------------------------------------+
| 0 0 | Mittleres Stück einer fragmentierten Benutzernachricht |
+----------------------------------------------------------+
| 0 1 | Letztes Stück einer fragmentierten Benutzernachricht |
+----------------------------------------------------------+
| 1 1 | Nicht fragmentierte Nachricht |
============================================================
| Tabelle 1: Fragment-Beschreibungsflags |
============================================================

Wenn eine Benutzernachricht in mehrere Chunks fragmentiert wird, werden die TSNs vom Empfänger verwendet, um die Nachricht wiederzusammenzusetzen. Dies bedeutet, dass die TSNs für jedes Fragment einer fragmentierten Benutzernachricht streng sequentiell sein MÜSSEN (MUST).

Länge (Length): 16 Bits (vorzeichenlose Ganzzahl)

Dieses Feld gibt die Länge des DATA-Chunks in Bytes vom Anfang des Typfelds bis zum Ende des Benutzerdatenfelds an, ohne Auffüllung. Ein DATA-Chunk mit einem Byte Benutzerdaten wird die Länge auf 17 gesetzt haben (was 17 Bytes anzeigt).

Ein DATA-Chunk mit einem Benutzerdatenfeld der Länge L wird das Längenfeld auf (16 + L) gesetzt haben (was 16+L Bytes anzeigt), wobei L größer als 0 sein MUSS (MUST).

TSN: 32 Bits (vorzeichenlose Ganzzahl)

Dieser Wert repräsentiert die TSN für diesen DATA-Chunk. Der gültige Bereich von TSN ist von 0 bis 4294967295 (2**32 - 1). TSN kehrt nach Erreichen von 4294967295 zu 0 zurück.

Stream-Identifikator S (Stream Identifier S): 16 Bits (vorzeichenlose Ganzzahl)

Identifiziert den Stream, zu dem die folgenden Benutzerdaten gehören.

Stream-Sequenznummer n (Stream Sequence Number n): 16 Bits (vorzeichenlose Ganzzahl)

Dieser Wert repräsentiert die Stream-Sequenznummer der folgenden Benutzerdaten innerhalb des Streams S. Der gültige Bereich ist 0 bis 65535.

Wenn eine Benutzernachricht von SCTP für den Transport fragmentiert wird, MUSS (MUST) die gleiche Stream-Sequenznummer in jedem der Fragmente der Nachricht getragen werden.

Nutzlast-Protokoll-Identifikator (Payload Protocol Identifier): 32 Bits (vorzeichenlose Ganzzahl)

Dieser Wert repräsentiert einen von der Anwendung (oder oberen Schicht) angegebenen Protokoll-Identifikator. Dieser Wert wird von seiner oberen Schicht an SCTP übergeben und an seinen Peer gesendet. Dieser Identifikator wird nicht von SCTP verwendet, kann aber von bestimmten Netzwerkentitäten sowie von der Peer-Anwendung verwendet werden, um den Typ der in diesem DATA-Chunk getragenen Informationen zu identifizieren. Dieses Feld muss auch in fragmentierten DATA-Chunks gesendet werden (um sicherzustellen, dass es für Agenten in der Mitte des Netzwerks verfügbar ist). Beachten Sie, dass dieses Feld NICHT von einer SCTP-Implementierung berührt wird; daher ist seine Byte-Reihenfolge NICHT notwendigerweise Big Endian. Die obere Schicht ist für jede Byte-Reihenfolge-Konvertierung in diesem Feld verantwortlich.

Der Wert 0 zeigt an, dass von der oberen Schicht kein Anwendungs-Identifikator für diese Nutzdaten angegeben ist.

Benutzerdaten (User Data): variable Länge

Dies sind die Nutzlast-Benutzerdaten. Die Implementierung MUSS (MUST) das Ende der Daten auf eine 4-Byte-Grenze mit allen Null-Bytes auffüllen. Jede Auffüllung DARF NICHT (MUST NOT) im Längenfeld enthalten sein. Ein Sender DARF niemals (MUST never) mehr als 3 Bytes Auffüllung hinzufügen.

3.3.2. Initiierung (Initiation, INIT) (1)

Dieser Chunk wird verwendet, um eine SCTP-Assoziation zwischen zwei Endpunkten zu initiieren. Das Format des INIT-Chunks ist unten dargestellt:

     0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 | Chunk Flags | Chunk Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initiate Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertised Receiver Window Credit (a_rwnd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Outbound Streams | Number of Inbound Streams |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initial TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ Optional/Variable-Length Parameters /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Der INIT-Chunk enthält die folgenden Parameter. Sofern nicht anders angegeben, MUSS (MUST) jeder Parameter nur einmal im INIT-Chunk enthalten sein.

         Feste Parameter                      Status
----------------------------------------------
Initiate Tag Obligatorisch
Advertised Receiver Window Credit Obligatorisch
Number of Outbound Streams Obligatorisch
Number of Inbound Streams Obligatorisch
Initial TSN Obligatorisch

Variable Parameter Status Typwert
-------------------------------------------------------------
IPv4 Address (Hinweis 1) Optional 5
IPv6 Address (Hinweis 1) Optional 6
Cookie Preservative Optional 9
Reserved for ECN Capable (Hinweis 2) Optional 32768 (0x8000)
Host Name Address (Hinweis 3) Optional 11
Supported Address Types (Hinweis 4) Optional 12

Hinweis 1: Die INIT-Chunks können mehrere Adressen enthalten, die IPv4 und/oder IPv6 in beliebiger Kombination sein können.

Hinweis 2: Das Feld ECN Capable ist für die zukünftige Verwendung der expliziten Überlastnachricht reserviert.

Hinweis 3: Ein INIT-Chunk DARF NICHT (MUST NOT) mehr als einen Host Name Address-Parameter enthalten. Darüber hinaus DARF (MUST NOT) der Sender des INIT keine anderen Adresstypen mit der Host Name Address im INIT kombinieren. Der Empfänger des INIT MUSS (MUST) alle anderen Adresstypen ignorieren, wenn der Host Name Address-Parameter im empfangenen INIT-Chunk vorhanden ist.

Hinweis 4: Dieser Parameter gibt, wenn vorhanden, alle Adresstypen an, die der sendende Endpunkt unterstützen kann. Das Fehlen dieses Parameters zeigt an, dass der sendende Endpunkt jeden Adresstyp unterstützen kann.

IMPLEMENTIERUNGSHINWEIS: Wenn ein INIT-Chunk mit bekannten Parametern empfangen wird, die keine optionalen Parameter des INIT-Chunks sind, dann SOLLTE (SHOULD) der Empfänger den INIT-Chunk verarbeiten und ein INIT ACK zurücksenden. Der Empfänger des INIT-Chunks KANN (MAY) später einen ERROR-Chunk mit dem COOKIE ACK-Chunk bündeln. Restriktive Implementierungen KÖNNEN (MAY) jedoch einen ABORT-Chunk als Antwort auf den INIT-Chunk zurücksenden.

Das Chunk Flags-Feld in INIT ist reserviert, und alle Bits darin sollten vom Sender auf 0 gesetzt und vom Empfänger ignoriert werden. Die Sequenz von Parametern innerhalb eines INIT kann in beliebiger Reihenfolge verarbeitet werden.

Initiate Tag: 32 Bits (vorzeichenlose Ganzzahl)

Der Empfänger des INIT (die antwortende Seite) zeichnet den Wert des Initiate Tag-Parameters auf. Dieser Wert MUSS (MUST) in das Verifizierungs-Tag-Feld jedes SCTP-Pakets eingefügt werden, das der Empfänger des INIT innerhalb dieser Assoziation überträgt.

Das Initiate Tag darf jeden Wert außer 0 haben. Siehe Abschnitt 5.3.1 für mehr über die Auswahl des Tag-Werts.

Wenn festgestellt wird, dass der Wert des Initiate Tags in einem empfangenen INIT-Chunk 0 ist, MUSS (MUST) der Empfänger dies als Fehler behandeln und die Assoziation durch Übertragung eines ABORT schließen.

Angekündigter Empfänger-Fenster-Kredit (Advertised Receiver Window Credit, a_rwnd): 32 Bits (vorzeichenlose Ganzzahl)

Dieser Wert repräsentiert den dedizierten Pufferspeicher in Anzahl von Bytes, den der Sender des INIT in Verbindung mit diesem Fenster reserviert hat. Während der Lebensdauer der Assoziation SOLLTE (SHOULD NOT) dieser Pufferspeicher nicht verringert werden (d.h. dedizierte Puffer von dieser Assoziation weggenommen werden); jedoch KANN (MAY) ein Endpunkt den Wert von a_rwnd ändern, den er in SACK-Chunks sendet.

Anzahl der ausgehenden Streams (Number of Outbound Streams, OS): 16 Bits (vorzeichenlose Ganzzahl)

Definiert die Anzahl der ausgehenden Streams, die der Sender dieses INIT-Chunks in dieser Assoziation erstellen möchte. Der Wert 0 DARF NICHT (MUST NOT) verwendet werden.

Hinweis: Ein Empfänger eines INIT mit dem OS-Wert auf 0 gesetzt SOLLTE (SHOULD) die Assoziation abbrechen.

Anzahl der eingehenden Streams (Number of Inbound Streams, MIS): 16 Bits (vorzeichenlose Ganzzahl)

Definiert die maximale Anzahl von Streams, die der Sender dieses INIT-Chunks dem Peer-Ende erlaubt, in dieser Assoziation zu erstellen. Der Wert 0 DARF NICHT (MUST NOT) verwendet werden.

Hinweis: Es gibt keine Verhandlung über die tatsächliche Anzahl von Streams, sondern die beiden Endpunkte werden das min(requested, offered) verwenden. Siehe Abschnitt 5.1.1 für Details.

Hinweis: Ein Empfänger eines INIT mit dem MIS-Wert von 0 SOLLTE (SHOULD) die Assoziation abbrechen.

Initiale TSN (Initial TSN, I-TSN): 32 Bits (vorzeichenlose Ganzzahl)

Definiert die initiale TSN, die der Sender verwenden wird. Der gültige Bereich ist von 0 bis 4294967295. Dieses Feld KANN (MAY) auf den Wert des Initiate Tag-Felds gesetzt werden.

3.3.2.1. Optionale/Variable-Länge-Parameter in INIT

Die folgenden Parameter folgen dem Typ-Länge-Wert-Format, wie in Abschnitt 3.2.1 definiert. Alle Typ-Länge-Wert-Felder MÜSSEN (MUST) nach den im vorherigen Abschnitt definierten Feldern fester Länge kommen.

IPv4-Adress-Parameter (5)

     0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 5 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IPv4-Adresse: 32 Bits (vorzeichenlose Ganzzahl)

Enthält eine IPv4-Adresse des sendenden Endpunkts. Sie ist binär kodiert.

IPv6-Adress-Parameter (6)

     0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 6 | Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IPv6-Adresse: 128 Bits (vorzeichenlose Ganzzahl)

Enthält eine IPv6 [RFC2460] Adresse des sendenden Endpunkts. Sie ist binär kodiert.

Hinweis: Ein Sender DARF NICHT (MUST NOT) eine IPv4-gemappte IPv6-Adresse [RFC4291] verwenden, sondern sollte stattdessen einen IPv4-Adress-Parameter für eine IPv4-Adresse verwenden.

In Kombination mit der Quellportnummer im SCTP-gemeinsamen Header zeigt der in einem IPv4- oder IPv6-Adress-Parameter übergebene Wert eine Transportadresse an, die der Sender des INIT für die zu initiierende Assoziation unterstützen wird. Das heißt, während der Lebensdauer dieser Assoziation kann diese IP-Adresse im Quelladressfeld eines IP-Datagramms erscheinen, das vom Sender des INIT gesendet wird, und kann als Zieladresse eines IP-Datagramms verwendet werden, das vom Empfänger des INIT gesendet wird.

Mehr als ein IP-Adress-Parameter kann in einem INIT-Chunk enthalten sein, wenn der INIT-Sender mehrfach vernetzt ist. Darüber hinaus kann ein mehrfach vernetzter Endpunkt Zugriff auf verschiedene Netzwerktypen haben; somit kann mehr als ein Adresstyp in einem INIT-Chunk vorhanden sein, d.h. IPv4- und IPv6-Adressen sind im selben INIT-Chunk erlaubt.

Wenn das INIT mindestens einen IP-Adress-Parameter enthält, dann können die Quelladresse des IP-Datagramms, das den INIT-Chunk enthält, und alle zusätzlichen Adresse(n), die innerhalb des INIT bereitgestellt werden, vom Endpunkt, der das INIT empfängt, als Ziele verwendet werden. Wenn das INIT keine IP-Adress-Parameter enthält, MUSS (MUST) der Endpunkt, der das INIT empfängt, die mit dem empfangenen IP-Datagramm verbundene Quelladresse als seine einzige Zieladresse für die Assoziation verwenden.

Beachten Sie, dass das Nicht-Verwenden von IP-Adress-Parametern im INIT und INIT ACK eine Alternative ist, um eine Assoziation eher über eine NAT-Box funktionieren zu lassen.

Cookie Preservative (9)

Der Sender des INIT soll diesen Parameter verwenden, um dem Empfänger des INIT eine längere Lebensdauer des State Cookie vorzuschlagen.

     0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 9 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Suggested Cookie Life-Span Increment (msec.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vorgeschlagene Cookie-Lebensdauer-Erhöhung (Suggested Cookie Life-Span Increment): 32 Bits (vorzeichenlose Ganzzahl)

Dieser Parameter zeigt dem Empfänger an, wie viel Erhöhung in Millisekunden der Sender wünscht, dass der Empfänger zu seiner Standard-Cookie-Lebensdauer hinzufügt.

Dieser optionale Parameter sollte vom Sender zum INIT-Chunk hinzugefügt werden, wenn er versucht, eine Assoziation mit einem Peer erneut aufzubauen, bei dem sein vorheriger Versuch, die Assoziation aufzubauen, aufgrund eines veralteten Cookie-Operationsfehlers fehlgeschlagen ist. Der Empfänger KANN (MAY) wählen, die vorgeschlagene Cookie-Lebensdauer-Erhöhung aus eigenen Sicherheitsgründen zu ignorieren.


Hinweis: Dieses Dokument enthält die Abschnitte 3.3.1 und 3.3.2. Die verbleibenden Chunk-Definitionen (3.3.3 und darüber hinaus) werden in nachfolgenden Dokumenten fortgesetzt.