Stream Control Transmission Protocol

Stream Control Transmission Protocol (SCTP) - zuverlässiges, verbindungsorientiertes Netzwerkprotokoll der Transportschicht

Beschreibung

Es gehört zur Transportschicht und setzt auf einem potenziell unzuverlässigen, verbindungslosen Paketdienst der Netzwerkschicht auf

Das Stream Control Transmission Protocol

• oder SCTP erweitert TCP, will abeár gleichzeitig mit weniger Overhead auskommen
• Anfang der 1980er, in den frühen Jahren des Internets, hatten die Entwickler des Transmission Control Protocol (TCP) Anwendungen wie E-Mail und ftp im Hinterkopf, die zeitunkritisch sind und nur geringe Datenmengen erzeugen
• Es war für relativ unzuverlässige Leitungen ausgelegt und verfügt deshalb über umfangreiche Methoden zur Fehlersicherung und Flusssteuerung
• Die strikte Reihenfolgesicherung schafft aber Abhängigkeiten zwischen einzelnen Datenpaketen

UDP (User Datagram Protocol)

• als nachrichtenorientiertes Protokoll kommt ohne diesen Ballast aus
• bietet aber auch keine zuverlässige Sicherung gegen Übertragungsfehler
• Das wiederholte Senden fehlerhafter Pakete, das Erkennen duplizierter Nachrichten und die Sicherung der Reihenfolge müssen hier höhere Softwareschichten übernehmen
• Das verbindungslose UDP eignet sich beispielsweise gut für die Sprachübertragung, in der verbindungsorientierte Protokolle eher kontraproduktiv wären

Im Jahr 2000 entwarf die IETF auf Betreiben der Telko-Provider ein drittes Layer-4-Protokoll für den TCP/IP-Stack

• Das Stream Control Transmission Protocol (SCTP) nach RFC 4960 soll einerseits große Datenmengen zuverlässig durch komplexe Netze geleiten, andererseits das Senden von Signalisierungsdaten vereinfachen
• Es arbeitet wie TCP verbindungsorientiert, ersetzt aber die TCP-Connections durch die weiter gefassten SCTP-Assoziationen

Das Stream Control Transmission Protocol (SCTP)

• ist ein Computernetzwerk Kommunikationsprotokoll in der Transportschicht der Internet-Protokollsuite
• Ursprünglich für den Transport von Nachrichten des Signaling System 7 (SS7) in der Telekommunikation gedacht, bietet das Protokoll die nachrichtenorientierte Funktion des User Datagram Protocol (UDP) und gewährleistet gleichzeitig einen zuverlässigen, sequenziellen Transport von Nachrichten mit Staukontrolle wie das Transmission Control Protocol (TCP)
• Im Gegensatz zu UDP und TCP unterstützt das Protokoll Multihoming und redundante Pfade, um die Ausfallsicherheit und Zuverlässigkeit zu erhöhen

SCTP wurde von der Internet Engineering Task Force (IETF) in Vorlage:IETF RFC standardisiert

• Die SCTP-Referenzimplementierung wurde als Teil von FreeBSD, Version 7, veröffentlicht und ist seitdem in großem Umfang auf andere Plattformen portiert worden

Formale Aufsicht

Die IETF Signaling Transport (SIGTRAN) Arbeitsgruppe definierte das Protokoll (Nummer 132) im Oktober 2000, und die IETF Arbeitsgruppe Transport Area (TSVWG) pflegt es. Vorlage:IETF RFC definiert das Protokoll. Vorlage:IETF RFC bietet eine Einführung

Eigenschaften und Funktionen

SCTP wurde von der Internet Engineering Task Force (IETF) als neues Transportprotokoll vorgeschlagen und im Oktober 2000 in dem Standarddokument RFC 2960 veröffentlicht

• Die Spezifikation wurde im September 2007 durch RFC 4960 und im Juni 2022 durch RFC 9260 ersetzt
• Eine Einführung findet sich in RFC 3286

Das zuständige Gremium bei der IETF ist die Arbeitsgruppe Signaling Transport, kurz SIGTRAN

Als Transportprotokoll steht SCTP auf derselben Stufe des TCP/IP-Referenzmodells wie TCP und UDP (Schicht 4 des OSI-Modells)

SCTP realisiert das Konzept einer Association

• Hier wird eine Verbindung aufgebaut, in der mehrere Nachrichten-Datenströme in sich reihenfolgenerhaltend (untereinander aber potentiell nicht-reihenfolgenerhaltend) transportiert werden
• Zusätzlich können einzelne, zum Beispiel dringende, Datagramme separat und außer der Reihe verschickt werden, die dadurch eventuell die In-Order-Datenströme „überholen“

SCTP kennt außerdem Multistreaming und Multihoming

• (ein Host mit mehreren gültigen IP-Adressen)
• Es werden Heartbeats verwendet, um aktiv auf Verbindungsabriss zu testen

Anders als TCP zeigt sich SCTP resistent gegen SYN-Flooding

• , eine Denial-of-Service-Attacke, bei der durch halboffene Verbindungen die Ressourcen des Servers aufgebraucht werden
• Dazu verwendet es einen sogenannten Vier-Wege-Handshake
• Hierbei speichert der Server bei einer Verbindungsanfrage (INIT-Paket) keine Zustandsinformationen, sondern schickt diese in Form eines Cookies (INIT-ACK-Paket) an den Client
• Der Client muss dieses Cookie in seine Antwort (COOKIE-ECHO-Paket) einfügen und wird damit vom Server als zum Verbindungsaufbau berechtigt erkannt, was dieser ihm bestätigt (COOKIE-ACK-Paket)
• Ein ähnliches Verfahren ist mit TCP ebenfalls möglich, siehe SYN-Cookies

Ursprünglich wurde SCTP als Transportprotokoll definiert, um Zeichengabenachrichten (SS7) aus Telefonnetzen auch über IP-Netzwerke übertragen zu können

• Bei der Entwicklung stand insbesondere die Zuverlässigkeit des Protokolls im Vordergrund
• SCTP ist aber auch für andere Anwendungen geeignet, da es Vorteile von TCP und UDP vereint
• Eine wichtige, auf SCTP aufbauende Anwendung ist Reliable Server Pooling (RSerPool)

SCTP verwendet für Fluss- und Überlastkontrolle ähnliche Algorithmen wie TCP, verhält sich also in einem gemischten Netz (SCTP und TCP) neutral

TCP, UDP und SCTP im Vergleich

Funktion	TCP	UDP	SCTP
verbindungsorientierte Übertragung	✓	–	✓
gesicherte Übertragung	✓	–	✓
ungesicherte Übertragung	–	✓	✓
Flusskontrolle	✓	–	✓
Überlaststeuerung	✓	–	✓
Steuerung der maximalen Paketgröße (Path MTU Discovery)	✓	–	✓
Multihoming	–	–	✓
Multistreaming	–	–	✓

Dabei lassen sich jedem Endpunkt mehrere IP-Adressen zuordnen, was man als Multihoming bezeichnet

• Das entkoppelt die logische Verbindung, die Assoziation, noch weiter von den physischen Pfaden
• Durch die Nutzung mehrerer Übertragungswege und Provider lässt sich die Verfügbarkeit erhöhen
• Voraussetzung ist allerdings, dass Pfade nicht über dieselben Netzknoten führen

Nicht aktive Pfade werden laufend auf Verfügbarkeit überprüft

• Ist der Backup-Pfad nicht erreichbar, wird er gestrichen
• Damit ist im Fehlerfall ein schnelles Umschalten ohne Routing möglich
• Ein Load Sharing über mehrere Pfade wie beim Multipath TCP (MPTCP) war ursprünglich nicht vorgesehen
• Das liefert der Entwurf von IEEE und IETF zum Concurrent Multipath Transfer (CMT-SCTP) nach

SCTP nutzt wie TCP Sequenznummern für jede Nachricht, deren Empfang die Gegenstelle bestätigt (Selective Acknowledgement)

• Statt eines Byte-Stroms überträgt SCTP Nachrichtenblöcke, sogenannte Messages, die mehr Spielraum bieten: Einerseits lassen sich große Nachrichten über mehrere Pakete verteilen, wenn sie die maximale Paketgröße (Path MTU) überschreiten
• Andererseits kann SCTP mehrere kleine Nachrichten in einem Paket zusammenfassen (Multiplexing)

Damit eignet es sich gleichermaßen als Signalisierungsprotokoll und für die Übertragung von Datenströmen

• Hierzu fasst es Pakete zu Streams zusammen und erlaubt die parallele Übertragung in mehreren Streams
• Während TCP alle Daten in die gleiche Reihenfolge presst, in der sie gesendet wurden, lässt SCTP pro Stream die Festlegung zu, ob eine Sicherung der Reihenfolge vorgenommen wird oder nicht
• Das verhindert, dass verloren gegangene Daten eines Streams den Fluss der anderen Streams behindern, ein als Head-of-Line Blocking bezeichnetes Phänomen
• Mit der Erweiterung SCTP-PR (Partial Reliability) ist es zudem möglich, ungesicherte Streams zu definieren, bei denen verlorene Pakete nicht erneut gesendet werden
• Anders als bei UDP greift aber hier die Überlaststeuerung

Durch die Aufteilung der Daten in mehrere Streams mit unterschiedlichen Eigenschaften lassen sich gleichzeitig UDP- und TCP-ähnliche Verbindungen zwischen zwei Endpunkten aufrechterhalten

• Zwar ließen sich auch getrennte TCP- und UDP-Verbindungen aufbauen, was aber mit einem größeren Overhead verbunden ist
• Die Stärke von SCTP liegt gerade in der Verwaltung mehrerer paralleler Streams. Überlaststeuerung, Bandbreitenreservierung und Multihoming gelten jeweils für die gesamte Assoziation, allerdings separat für jede IP-Adresse
• Einen einzelnen Stream überträgt TCP schneller, weshalb es seine Bedeutung weiterhin behält

SCTP werkelt bereits unauffällig in vielen Netzwerkanwendungen

• In den Blickpunkt rückt es gegenwärtig wieder durch die Ausbreitung von IP-Netzen in Bereiche, die zuvor InfiniBand oder Fibre Channel vorbehalten waren, etwa durch iWARP (Internet Wide Area RDMA Protocol), das Direktspeicherzugriffe über IP erlaubt

Merkmale

Zu den Merkmalen von SCTP gehören

• Zuverlässige Übertragung sowohl von geordneten als auch von ungeordneten Datenströmen
• Multihoming-Unterstützung, bei der ein oder beide Endpunkte einer Verbindung aus mehr als einer IP-Adresse bestehen können, was ein transparentes Failover zwischen redundanten Netzwerkpfaden ermöglicht
• Zustellung von Datenpaketen innerhalb unabhängiger Ströme eliminiert unnötiges Head-of-Line-Blocking, im Gegensatz zur TCP-Byte-Stream-Zustellung
• Explizite partielle Zuverlässigkeit
• Pfadauswahl und -überwachung zur Auswahl eines primären Datenübertragungspfads und zur Prüfung der Konnektivität des Übertragungspfads
• Validierungs- und Bestätigungsmechanismen zum Schutz vor Flooding-Angriffen und zur Benachrichtigung über duplizierte oder fehlende Datenpakete
• Verbesserte Fehlererkennung, geeignet für Ethernet Jumbo Frames

Die Entwickler von SCTP hatten es ursprünglich für die Übertragung von Telefongesprächen (d. h. Signalsystem 7) über das Internetprotokoll vorgesehen, mit dem Ziel, einige der Zuverlässigkeitsmerkmale des SS7-Signalisierungsnetzes in IP zu duplizieren

• Diese Bemühungen der IETF sind als SIGTRAN bekannt
• In der Zwischenzeit wurden andere Anwendungen vorgeschlagen, etwa das Diameter-Protokoll und Reliable Server Pooling (RSerPool)

Message-based Multi-Streaming

SCTP-Anwendungen übermitteln Daten zur Übertragung in Nachrichten (Byte-Gruppen) an die SCTP-Transportschicht

• SCTP unterteilt Nachrichten und Kontrollinformationen in separate Chunks (Daten- und Kontrollchunks), die jeweils durch einen Chunk-Header gekennzeichnet sind
• Das Protokoll kann eine Nachricht in mehrere Datenchunks aufteilen, aber jeder Datenchunk enthält nur die Daten einer einzigen Benutzernachricht
• SCTP bündelt die Chunks zu SCTP-Paketen
• Das SCTP-Paket, das an das Internetprotokoll übergeben wird, besteht aus einem Paketkopf, SCTP-Kontrollbrocken (sofern erforderlich), gefolgt von SCTP-Datenbrocken (sofern verfügbar)

SCTP kann als nachrichtenorientiert bezeichnet werden, d. h. es transportiert eine Folge von Nachrichten (jeweils eine Gruppe von Bytes) und nicht wie TCP einen ununterbrochenen Strom von Bytes

• Wie bei UDP sendet ein Absender bei SCTP eine Nachricht in einem Vorgang, und genau diese Nachricht wird in einem Vorgang an den empfangenden Anwendungsprozess weitergeleitet
• Im Gegensatz dazu ist TCP ein strömungsorientiertes Protokoll, das Ströme von Bytes zuverlässig und in der richtigen Reihenfolge transportiert
• Bei TCP weiß der Empfänger jedoch nicht, wie oft die Senderanwendung den TCP-Transport aufgerufen hat, um ihm die zu sendenden Byte-Gruppen zu übergeben
• Beim Absender fügt TCP einfach weitere Bytes an eine Warteschlange von Bytes an, die darauf warten, über das Netz versendet zu werden, anstatt eine Warteschlange von einzelnen separaten ausgehenden Nachrichten zu führen, die als solche erhalten werden müssen

Der Begriff Multi-Streaming bezieht sich auf die Fähigkeit von SCTP, mehrere unabhängige Ströme von Datenpaketen parallel zu übertragen, z. B.  Bilder einer Webseite gleichzeitig mit dem Text der Webseite

• Im Wesentlichen geht es darum, mehrere Verbindungen in einer einzigen SCTP-Verbindung zu bündeln und mit Nachrichten (oder Chunks) statt mit Bytes zu arbeiten

TCP bewahrt die Byte-Reihenfolge im Datenstrom, indem es jedem Segment eine Byte-Sequenznummer beifügt

• SCTP hingegen weist jeder Nachricht, die in einem Datenstrom gesendet wird, eine Sequenznummer oder eine Message-ID zu
• Die DATA chunk verwendet eine Sequenznummer für geordnete Nachrichten, die I-DATA chunk, die einige Probleme mit dem ursprünglichen DATA chunk löst, verwendet eine Message-ID für alle Nachrichten
• Dies ermöglicht eine unabhängige Anordnung von Nachrichten in verschiedenen Streams
• Die Reihenfolge der Nachrichten ist bei SCTP jedoch optional; eine empfangende Anwendung kann sich dafür entscheiden, die Nachrichten in der Reihenfolge des Empfangs und nicht in der Reihenfolge des Versands zu verarbeiten

Motivation und Einführung

TCP war das wichtigste Mittel zur zuverlässigen Datenübertragung im Internet

• Allerdings hat TCP bei verschiedenen Anwendungen zu Einschränkungen geführt
• Aus Vorlage:IETF RFC:
• TCP bietet sowohl eine zuverlässige Datenübertragung als auch eine strikte Reihenfolge der Datenübermittlung
• Einige Anwendungen benötigen eine zuverlässige Übertragung ohne Einhaltung der Reihenfolge, während andere mit einer teilweisen Reihenfolge der Daten zufrieden wären
• In beiden Fällen verursacht die Head-of-Line-Blocking-Eigenschaft von TCP unnötige Verzögerungen
• Für Anwendungen, die verschiedene Datensätze oder Nachrichten austauschen, erfordert die stromorientierte Natur von TCP die Hinzufügung expliziter Markierungen oder anderer Kodierungen, um die einzelnen Datensätze abzugrenzen
• Um zu vermeiden, dass viele kleine IP-Pakete gesendet werden, wo ein einziges größeres Paket ausgereicht hätte, kann die TCP-Implementierung die Übertragung von Daten verzögern, während sie auf möglicherweise weitere Daten wartet, die sich in der Warteschlange der Anwendung befinden (Nagle-Algorithmus)
• Wenn eine solche kleine Verzögerung unerwünscht ist, muss die Anwendung von Fall zu Fall ausdrücklich eine unverzögerte Übertragung mit Hilfe der push facility anfordern (d. h. durch Setzen des PSH-Flags im TCP-Paketkopf)
• Bei SCTP hingegen kann die unverzögerte Übertragung als Standard für eine Assoziation konfiguriert werden, wodurch unerwünschte Verzögerungen vermieden werden, allerdings auf Kosten eines höheren Übertragungs-Overheads
• Die begrenzte Reichweite von TCP-Sockets erschwert die Aufgabe, hochverfügbare Datenübertragungen mit multihomed Hosts zu ermöglichen
• TCP ist relativ anfällig für Denial-of-Service-Angriffe, wie z. B. SYN-Angriffe

Die Akzeptanz wurde durch mangelndes Bewusstsein, fehlende Implementierungen (insbesondere in Microsoft Windows), fehlende Anwendungsunterstützung und fehlende Netzwerkunterstützung gebremst

Multihoming

SCTP bietet redundante Pfade, um die Zuverlässigkeit zu erhöhen

Jeder SCTP-Endpunkt muss die Erreichbarkeit der primären und redundanten Adressen des entfernten Endpunkts mit Hilfe eines heartbeat überprüfen

• Jeder SCTP-Endpunkt muss die Heartbeats, die er vom entfernten Endpunkt empfängt, quittieren

Wenn SCTP eine Nachricht an eine entfernte Adresse sendet, wird die Quellschnittstelle nur durch die Routing-Tabelle des Hosts (und nicht durch SCTP) bestimmt

Beim asymmetrischen Multihoming unterstützt einer der beiden Endpunkte kein Multihoming

Bei lokalem Multihoming und entferntem Single-Homing schlägt die SCTP-Zuordnung fehl, wenn die entfernte primäre Adresse nicht erreichbar ist, selbst wenn ein alternativer Pfad möglich ist

Paketstruktur

Ein SCTP-Paket besteht aus zwei grundlegenden Abschnitten

1. Dem common header, der die ersten 12 Bytes einnimmt und blau hervorgehoben ist
2. Die data chunks, die den restlichen Teil des Pakets einnehmen

• Der erste Chunk ist grün hervorgehoben, und der letzte von N Chunks (Chunk N) ist rot hervorgehoben

Bits	0–7								8–15								16–23								24–31
+0	Source port																Destination port
32	Verification tag
64	Checksum
96	Chunk 1 type								Chunk 1 flags								Chunk 1 length
128	Chunk 1 data
…	…
…	Chunk N type								Chunk N flags								Chunk N length
…	Chunk N data

Jeder Chunk beginnt mit einem Ein-Byte-Typ-Identifikator, wobei 15 Chunk-Typen durch Vorlage:IETF RFC und mindestens 5 weitere durch zusätzliche RFCs definiert sind

• Siehe SCTP-Paketstruktur für weitere Einzelheiten
• Acht Flaggenbits, ein Zwei-Byte-Längenfeld und die Daten bilden den Rest des Chunks
• Wenn der Chunk kein Vielfaches von 4 Bytes ist (d.h
• die Länge ist kein Vielfaches von 4), wird er mit Nullen aufgefüllt, die nicht in die Chunk-Länge eingerechnet werden
• Das Zwei-Byte-Längenfeld begrenzt jedes Chunk auf eine Länge von 65.535 Byte (einschließlich der Felder Typ, Flags und Länge)

Sicherheit

Obwohl die Verschlüsselung nicht Teil des ursprünglichen SCTP-Entwurfs war, wurde SCTP mit Merkmalen zur Verbesserung der Sicherheit entwickelt, z. B.  4-Wege-Handshake (im Vergleich zu TCP 3-Wege-Handshake) zum Schutz vor SYN-Flooding-Angriffen und große "Cookies" zur Überprüfung der Verbindung und Authentizität

Auch die Zuverlässigkeit war ein wichtiger Bestandteil des Sicherheitsdesigns von SCTP

• Multihoming ermöglicht es, eine Verbindung auch dann aufrechtzuerhalten, wenn einige Routen und Schnittstellen ausgefallen sind
• Dies ist für SIGTRAN von besonderer Bedeutung, da es SS7 über ein IP-Netz unter Verwendung von SCTP überträgt und eine hohe Ausfallsicherheit bei Verbindungsausfällen erfordert, um den Telekommunikationsdienst auch bei Netzanomalien aufrechtzuerhalten

SCTP ist manchmal ein guter Kandidat für Fingerprinting

• Einige Betriebssysteme werden mit aktivierter SCTP-Unterstützung ausgeliefert, und da SCTP nicht so bekannt ist wie TCP oder UDP, wird es manchmal in Firewall- und Intrusion-Detection-Konfigurationen übersehen, so dass es oft einen Sondierungsverkehr zulässt

Implementations

The SCTP reference implementation runs on FreeBSD, Mac OS X, Microsoft Windows, and Linux

The following operating systems implement SCTP:

• AIX Version 5 and newer
• NetBSD
• FreeBSD, version 7 and above, contains the reference SCTP implementation
• HP-UX, 11i v2 and above
• illumos
• Linux kernel 2.4 and above
• QNX Neutrino Realtime OS,
• Tru64 with the Compaq SCTP add-on package
• Sun Solaris 10 and above
• VxWorks versions 6.2.x to 6.4.x, and 6.7 and newer

Third-party drivers:

• Microsoft Windows:
  • The SctpDrv kernel driver is a port of the BSD SCTP stack to Windows (Abandoned after 2012)
• MacOS:
  • SCTP Network Kernel Extension for Mac OS X

Userspace library:

• Portable SCTP userland stack
• The SCTP library
  • Windows XP port
• Oracle Java SE 7
• Erlang/OTP

The following applications implement SCTP:

• WebRTC
• NetFlow

Tunneling über UDP

In Ermangelung einer nativen SCTP-Unterstützung in Betriebssystemen ist es möglich, Tunnel SCTP über UDP, sowie TCP-API-Aufrufe auf SCTP-Aufrufe abzubilden, damit bestehende Anwendungen SCTP ohne Änderungen nutzen können

Alternativen

QUIC ist ein auf UDP aufbauendes ebenfalls zuverlässiges und verbindungsorientiertes Netzprotokoll auf Transportschicht

• Im Gegensatz zu SCTP ist es jedoch verschlüsselt da Transport Layer Security (TLS) zur kryptographischen Absicherung der Kommunikation integriert wurde
• QUIC wird von Protokollen wie HTTP/3 oder DNS over QUIC (DoQ) verwendet
• QUIC ist ebenfalls von IETF standardisiert; eine Google-Variante gQUIC wird parallel fortgeführt

Anhang

Siehe auch

• SCTP

• Transport layer|Comparison of transport layer protocols
• Session Initiation Protocol (SIP) – which may initiate multiple streams over SCTP, TCP, or UDP
• Multipath TCP – which allows a TCP connection to use multiple paths to maximize resource usage and increase redundancy
• Happy Eyeballs – originally designed for efficient selection of IPv4 or IPv6 for a connection; could also be adapted to select from different transport protocols such as TCP and SCTP

Dokumentation

RFC

RFC	Titel
2960	Stream Control Transmission Protocol (updated by RFC 3309 and obsoleted by RFC 4960)
3257	Stream Control Transmission Protocol Applicability Statement
3286	An Introduction to the Stream Control Transmission Protocol
3309	Stream Control Transmission Protocol (SCTP) Checksum Change (obsoleted by RFC 4960)
3436	Transport Layer Security over Stream Control Transmission Protocol
3554	On the Use of Stream Control Transmission Protocol (SCTP) with IPsec
3758	Stream Control Transmission Protocol (SCTP) Partial Reliability Extension
3873	Stream Control Transmission Protocol (SCTP) Management Information Base (MIB)
4460	Stream Control Transmission Protocol (SCTP) Specification Errata and Issues (obsoleted by RFC 9260)
4820	Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP)
4895	Authenticated Chunks for the Stream Control Transmission Protocol (SCTP)
4960	Stream Control Transmission Protocol
4960	Stream Control Transmission Protocol (obsoleted by RFC 9260)
5043	Stream Control Transmission Protocol (SCTP) Direct Data Placement (DDP) Adaptation
5061	Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration
5062	Security Attacks Found Against the Stream Control Transmission Protocol (SCTP) and Current Countermeasures
6096	Stream Control Transmission Protocol (SCTP) Chunk Flags Registration (obsoleted by RFC 9260)
6458	Sockets API Extensions for the Stream Control Transmission Protocol (SCTP)
6525	Stream Control Transmission Protocol (SCTP) Stream Reconfiguration
6951	UDP Encapsulation of Stream Control Transmission Protocol (SCTP) Packets for End-Host to End-Host Communication
7053	SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol (obsoleted by RFC 9260)
7496	Additional Policies for the Partially Reliable Stream Control Transmission Protocol Extension
7765	TCP and Stream Control Transmission Protocol (SCTP) RTO Restart
7829	SCTP-PF: A Quick Failover Algorithm for the Stream Control Transmission Protocol
8540	Stream Control Transmission Protocol: Errata and Issues in RFC 4960 (obsoleted by RFC 9260)
9260	Stream Control Transmission Protocol

Links

Weblinks

1. https://de.wikipedia.org/wiki/Stream_Control_Transmission_Protocoloject Page]