Zum Hauptinhalt springen

6. Benutzerdatenübertragung (User Data Transfer)

Dieses Kapitel beschreibt den Mechanismus der Benutzerdatenübertragung zwischen SCTP-Endpunkten.

6.1. Übertragung von DATA-Chunks (Transmission of DATA Chunks)​

SCTP-Endpunkte tauschen Benutzernachrichten über DATA-Chunks auf einer etablierten Assoziation aus.

6.1.1. Nutzdaten (Payload Data)​

Der Sender SOLLTE "Path MTU Discovery" (wie in [RFC4821] definiert) verwenden, um die geeignete Fragmentierungsgröße für das Ziel zu bestimmen.

Der Sender KANN eine Benutzernachricht in mehrere DATA-Chunks fragmentieren, wobei jeder Chunk einen Teil der Benutzernachricht trägt. Der Empfänger wird die Stream-Sequenznummer (Stream Sequence Number) und die Fragmentierungs-Flags (B-Bit und E-Bit) verwenden, um die Nachricht wieder zusammenzusetzen.

Wenn eine Benutzernachricht in mehrere DATA-Chunks fragmentiert wird:

  • Das erste Fragment MUSS das B-Bit auf 1 und das E-Bit auf 0 setzen
  • Mittlere Fragmente MÜSSEN das B-Bit auf 0 und das E-Bit auf 0 setzen
  • Das letzte Fragment MUSS das B-Bit auf 0 und das E-Bit auf 1 setzen
  • Eine nicht fragmentierte Nachricht MUSS das B-Bit auf 1 und das E-Bit auf 1 setzen

Alle DATA-Chunks, die Fragmente derselben Benutzernachricht tragen, MÜSSEN denselben Stream-Identifier (SI) und dieselbe Stream-Sequenznummer (SSN) haben.

6.1.2. Übertragungssequenznummer (Transmission Sequence Number, TSN)​

Jeder DATA-Chunk MUSS eine gültige TSN enthalten. Die TSN ist eine 32-Bit-Sequenznummer, die mit dem während der Assoziationsinitialisierung ausgetauschten Initial TSN-Wert beginnt und für jeden gesendeten DATA-Chunk um 1 erhöht wird.

Der TSN-Raum ist zyklisch, wobei Vergleiche die Serial Number Arithmetic (wie in [RFC1982] definiert) verwenden.

Der Sender DARF NICHT reservierte TSN-Werte (d.h. TSNs außerhalb des vom Peer angekündigten Empfangsfensters) in DATA-Chunks verwenden.

6.1.3. Staukontrolle (Congestion Control)​

SCTP-Endpunkte MÜSSEN Staukontrolle implementieren, um Netzwerkstaus zu vermeiden. SCTP verwendet Staukontrollmechanismen ähnlich wie TCP.

Jede SCTP-Assoziation verwaltet die folgenden Staukontrollparameter:

  • cwnd (Staufenster, Congestion Window): Die Obergrenze der Daten, die ohne Bestätigung gesendet werden können
  • ssthresh (Slow-Start-Schwelle, Slow Start Threshold): Der Schwellenwert, der bestimmt, wann vom Slow Start zur Stauungsvermeidung gewechselt wird
  • rwnd (Empfangsfenster, Receiver Window): Der vom Peer angekündigte verfügbare Pufferspeicher

Die Menge unbestätigter Daten, die der Sender zu jedem Zeitpunkt übertragen kann, DARF min(cwnd, rwnd) NICHT überschreiten.

Slow Start:

  • Zu Beginn einer Assoziation oder nach einem Timeout wird cwnd auf höchstens 2*MTU gesetzt
  • Jedes Mal, wenn ein SACK empfangen wird und alle bestätigten Daten während des Slow Start gesendet wurden, wird cwnd um höchstens die Anzahl der bestätigten Bytes erhöht, aber die Erhöhung DARF MTU NICHT überschreiten

Stauungsvermeidung (Congestion Avoidance):

  • Wenn cwnd > ssthresh, wird cwnd pro RTT um höchstens 1*MTU erhöht
  • Implementierungen SOLLTEN "Appropriate Byte Counting" (wie in [RFC3465] definiert) verwenden

Fast Retransmit und Fast Recovery:

  • Wenn 4 aufeinanderfolgende SACKs denselben TSN als fehlend melden, SOLLTE der Sender diesen TSN sofort neu übertragen, ohne auf das Ablaufen des Neuübertragungstimers zu warten

6.1.4. Bündelung (Bundling)​

SCTP-Endpunkte KÖNNEN mehrere DATA-Chunks und Kontroll-Chunks in einem einzigen SCTP-Paket bündeln, solange die Gesamtgröße die aktuelle Pfad-MTU nicht überschreitet.

Vorteile der Bündelung umfassen:

  • Reduzierung des Paket-Header-Overheads
  • Verbesserte Netzwerkeffizienz
  • Reduzierung der Anzahl von Systemaufrufen

Der Sender SOLLTE versuchen, so viele Daten wie möglich in einem einzigen Paket zu bündeln, DARF jedoch NICHT die Übertragung von DATA-Chunks verzögern, nur um auf mehr Daten zum Bündeln zu warten.

6.2. Bestätigung beim Empfang von DATA-Chunks (Acknowledgement on Reception of DATA Chunks)​

Empfangende SCTP-Endpunkte MÜSSEN SACK (Selective Acknowledgement)-Chunks verwenden, um empfangene DATA-Chunks zu bestätigen.

6.2.1. SACK-Generierungsregeln (SACK Generation Rules)​

Der Empfänger SOLLTE die folgenden Regeln verwenden, um SACKs zu generieren:

  1. Verzögerte Bestätigung (Delayed Acknowledgement):

    • Der Empfänger SOLLTE NICHT sofort einen SACK für jedes empfangene Paket senden
    • Der Empfänger SOLLTE das Senden eines SACK um höchstens 200ms verzögern
    • Wenn ein zweites Paket empfangen wird, MUSS sofort ein SACK gesendet werden (keine weitere Verzögerung)

  2. Sofortige Bestätigungssituationen:

    • Wenn eine Lücke erkannt wird (außer der Reihe empfangener DATA-Chunk)
    • Wenn ein empfangener DATA-Chunk eine vorherige Lücke füllt
    • Wenn ein doppelter TSN empfangen wird

  3. SACK-Inhalt:

    • Cumulative TSN Ack: Der höchste konsekutiv empfangene TSN
    • Gap Ack Blocks: Angabe von Bereichen konsekutiver TSNs, die nach dem kumulativen Punkt empfangen wurden
    • Duplicate TSNs: Auflistung doppelt empfangener TSNs

6.2.2. SACK-Verarbeitung (SACK Processing)​

Beim Empfang eines SACK MUSS der Sender:

  1. Seinen kumulativen Bestätigungspunkt auf den im SACK angegebenen Cumulative TSN Ack aktualisieren
  2. In Gap Ack Blocks bestätigte DATA-Chunks als bestätigt markieren
  3. Staufenster und Slow-Start-Schwelle aktualisieren
  4. Neuübertragungen nach Bedarf planen

6.2.3. Empfangsfenster-Update (Receiver Window Update)​

Der SACK-Chunk enthält das advertised receiver window credit (a_rwnd), das den verfügbaren Pufferspeicher des Empfängers angibt.

Der Empfänger SOLLTE seinen verfügbaren Pufferspeicher im SACK genau melden. Der Empfänger DARF eine bereits angekündigte Fenstergröße NICHT reduzieren, es sei denn, er hat den entsprechenden Pufferspeicher verbraucht.

6.3. Verwaltung des Neuübertragungstimers (Management of Retransmission Timer)​

SCTP verwendet Neuübertragungstimer, um zuverlässige Übertragung sicherzustellen. Jede Ziel-Transportadresse verwaltet ihren eigenen Neuübertragungstimer.

6.3.1. RTO-Berechnung (RTO Calculation)​

Das Retransmission Timeout (RTO) wird mit einem ähnlichen Algorithmus wie TCP berechnet:

SRTT = Geglättete Rundlaufzeit (Smoothed Round-Trip Time)
RTTVAR = Rundlaufzeit-Variation (Round-Trip Time Variation)

Anfangswerte:
RTO.Initial = 3 Sekunden (empfohlener Wert)
RTO.Min = 1 Sekunde
RTO.Max = 60 Sekunden

Erste RTT-Messung (R):
SRTT = R
RTTVAR = R/2
RTO = SRTT + 4 * RTTVAR

Nachfolgende RTT-Messungen (R'):
RTTVAR = (1 - Beta) * RTTVAR + Beta * |SRTT - R'|
SRTT = (1 - Alpha) * SRTT + Alpha * R'
RTO = SRTT + 4 * RTTVAR

Wobei: Alpha = 1/8, Beta = 1/4

Bei jeder Neuübertragung SOLLTE das RTO verdoppelt werden (exponentieller Rückzug), bis RTO.Max erreicht ist.

6.3.2. Timer-Regeln (Timer Rules)​

T3-rtx-Timer (Neuübertragungstimer):

  • Wenn ein DATA-Chunk zum ersten Mal an ein Ziel gesendet wird und der T3-rtx-Timer für dieses Ziel nicht läuft, MUSS er gestartet werden
  • Wenn alle an ein Ziel gesendeten unbestätigten DATA-Chunks bestätigt werden, MUSS der T3-rtx-Timer für dieses Ziel gestoppt werden
  • Wenn der T3-rtx-Timer abläuft, MUSS der älteste unbestätigte DATA-Chunk an diesem Ziel neu übertragen werden

T3-rtx-Timeout-Behandlung:

  1. Ziel als inaktiv markieren (falls zutreffend)
  2. ssthresh auf max(cwnd/2, 4*MTU) setzen
  3. cwnd auf 1*MTU setzen
  4. Ältesten unbestätigten DATA-Chunk neu übertragen
  5. RTO verdoppeln

6.3.3. Heartbeat-Mechanismus (Heartbeat Mechanism)​

Um die Erreichbarkeit des Ziels zu überwachen, SOLLTEN SCTP-Endpunkte regelmäßig HEARTBEAT-Chunks an jedes inaktive Ziel senden.

Das HEARTBEAT-Intervall SOLLTE konfigurierbar sein, mit einem empfohlenen Standardwert von 30 Sekunden.

Wenn ein HEARTBEAT gesendet wird:

  • Heartbeat-Timer starten
  • Sendezeitstempel und Zieladressinformationen im HEARTBEAT einfügen

Wenn ein HEARTBEAT ACK empfangen wird:

  • RTT berechnen
  • RTO aktualisieren
  • Ziel als aktiv markieren

Wenn HEARTBEAT abläuft (kein HEARTBEAT ACK empfangen):

  • Fehlerzähler des Ziels erhöhen
  • Wenn Fehlerzähler Schwellenwert überschreitet, Ziel als inaktiv markieren

6.4. Multi-Homed SCTP-Endpunkte (Multi-Homed SCTP Endpoints)​

SCTP unterstützt Multi-Homed-Endpunkte, d.h. Endpunkte mit mehreren IP-Adressen.

6.4.1. Primärer und alternative Pfade (Primary and Alternate Paths)​

Jeder SCTP-Endpunkt verwaltet:

  • Primärer Pfad (Primary Path): Der bevorzugte Pfad für normale Datenübertragung
  • Alternative Pfade (Alternate Paths): Pfade, die verwendet werden, wenn der primäre Pfad ausfällt

Der Endpunkt SOLLTE vorzugsweise Daten über den primären Pfad senden und alternative Pfade nur verwenden, wenn der primäre Pfad nicht verfügbar ist.

6.4.2. Pfadauswahl (Path Selection)​

Der Sender SOLLTE:

  • Den primären Pfad verwenden, um neue Daten zu senden
  • Alternative Pfade für Neuübertragungen verwenden (wenn der primäre Pfad ausgefallen ist)
  • Alle Pfade regelmäßig mit HEARTBEAT prüfen

Wenn der primäre Pfad als inaktiv bestimmt wird, SOLLTE der Sender einen aktiven alternativen Pfad als neuen primären Pfad auswählen.

6.4.3. Pfadfehlererkennung (Path Failure Detection)​

Ein Pfad gilt als ausgefallen, wenn:

  • Mehrere aufeinanderfolgende Übertragungsfehler auftreten (Path.Max.Retrans erreicht)
  • Mehrere aufeinanderfolgende HEARTBEAT-Timeouts auftreten

Wenn alle Pfade ausfallen, SOLLTE die Assoziation der oberen Schicht gemeldet werden und kann beendet werden.

6.5. Stream-Identifier und Stream-Sequenznummer (Stream Identifier and Stream Sequence Number)​

SCTP unterstützt mehrere gleichzeitige Streams, die jeweils durch einen Stream-Identifier (SI) eindeutig identifiziert werden.

Stream-Identifier (SI):

  • 16-Bit-Wert, Bereich 0 bis 65535
  • Anzahl der Streams wird während der Assoziationsinitialisierung ausgehandelt
  • Jeder Stream liefert Benutzernachrichten unabhängig

Stream-Sequenznummer (Stream Sequence Number, SSN):

  • 16-Bit-Wert, pro Stream unabhängig verwaltet
  • Wird verwendet, um Nachrichten beim Empfänger neu zu ordnen und wieder zusammenzusetzen
  • Pro Stream inkrementiert

Streams bieten eine logische Trennung von Nachrichten und ermöglichen es, dass mehrere unabhängige Datenströme gleichzeitig auf derselben Assoziation übertragen werden, wodurch Head-of-Line Blocking vermieden wird.

6.6. Geordnete und ungeordnete Zustellung (Ordered and Unordered Delivery)​

SCTP unterstützt zwei Nachrichtenzustellungsmodi:

6.6.1. Geordnete Zustellung (Ordered Delivery)​

Standardmodus. Nachrichten werden der oberen Schicht in der Reihenfolge zugestellt, in der sie innerhalb jedes Streams gesendet wurden.

  • U-Bit des DATA-Chunks auf 0 gesetzt
  • Stream-Sequenznummer gewährleistet Reihenfolge
  • Nachrichten auf demselben Stream werden in SSN-Reihenfolge zugestellt

6.6.2. Ungeordnete Zustellung (Unordered Delivery)​

Nachrichten werden der oberen Schicht sofort nach dem Empfang zugestellt, unabhängig von der Reihenfolge.

  • U-Bit des DATA-Chunks auf 1 gesetzt
  • Stream-Sequenznummer wird ignoriert
  • Wird sofort nach Empfang zugestellt, ohne auf vorherige Nachrichten zu warten

Ungeordnete Zustellung eignet sich für Echtzeit-Daten, die keine Reihenfolgegarantien erfordern (z.B. Videostreams).

6.7. Meldung von Lücken in empfangenen DATA-TSNs (Report Gaps in Received DATA TSNs)​

Wenn der Empfänger Lücken in der empfangenen Sequenz erkennt (d.h. außer der Reihe Daten empfängt), MUSS er diese Lücken im SACK melden.

Gap Ack Block-Format:

Gap Ack Block Start: Offset relativ zum Cumulative TSN Ack
Gap Ack Block End: Offset relativ zum Cumulative TSN Ack

Zum Beispiel, wenn Cumulative TSN Ack = 100 und TSNs 102-105 empfangen werden:

Gap Ack Block Start = 2  (102 - 100)
Gap Ack Block End = 5    (105 - 100)

Der Empfänger KANN mehrere Gap-Blöcke in einem einzigen SACK melden.

6.8. CRC32c-Prüfsummenberechnung (CRC32c Checksum Calculation)​

SCTP verwendet CRC32c (Castagnoli) als Prüfsummenalgorithmus und bietet eine stärkere Fehlererkennungsfähigkeit als einfache Prüfsummen.

6.8.1. Prüfsummenberechnungsschritte (Checksum Calculation Steps)​

  1. Das Prüfsummenfeld des SCTP-Pakets auf alle Nullen setzen
  2. CRC32c über das gesamte SCTP-Paket berechnen (einschließlich SCTP-Common-Header und aller Chunks)
  3. Den berechneten CRC32c-Wert im Prüfsummenfeld platzieren

CRC32c-Polynom:

x^32 + x^28 + x^27 + x^26 + x^25 + x^23 + x^22 + x^20 + x^19 + 
x^18 + x^14 + x^13 + x^11 + x^10 + x^9 + x^8 + x^6 + x^0

Der Empfänger MUSS die CRC32c-Prüfsumme jedes empfangenen SCTP-Pakets überprüfen. Wenn die Prüfsumme nicht übereinstimmt, MUSS das Paket stillschweigend verworfen werden.

Dieses Kapitel behandelt umfassend die Kernmechanismen der SCTP-Benutzerdatenübertragung, einschließlich zuverlässiger Übertragung, Staukontrolle, Multi-Homing-Unterstützung und Stream-Multiplexing.

Letztes Update am