Nack-orientiertes zuverlässiges Multicast
Nack-orientiertes zuverlässiges Multicast (Norm) ist a Transportschicht Internetprotokoll Entwickelt, um einen zuverlässigen Transport in Multicast Gruppen in Datennetzwerken. Es wird offiziell durch die definiert Internettechnik-Arbeitsgruppe (IETF) in Anfrage für Kommentare (RFC) 5740, die im November 2009 veröffentlicht wurde.
Norm arbeitet über dem User Datagram Protocol (UDP) und sorgt für eine zuverlässige Kommunikation, die auf einem negativen Anerkennung (NACK), dem Selektiv automatischen Wiederholungsanforderung (ARQ) -Mechanismus (ARQ) im Gegensatz zum ACK -Ansatz (positiver Anerkennung), den das Standardübertragungs -Steuerungsprotokoll (TCP) verwendet, verwendet. Mit anderen Worten, Empfänger, die Norm verwenden, senden nur Feedback, wenn sie kein Paket erhalten, im Gegensatz zum TCP -Modell, bei dem Empfänger regelmäßig als Teil des IT -Protokollbetriebs bestätigt werden. Dies ermöglicht die Unterstützung von groß angelegten Empfängergruppen.
Um eine weitere Skalierbarkeit zu unterstützen, verwendet Norm auch die Codierung des Paketlöschers unter Verwendung von FEC -Codes (Vorwärtsfehlerkorrektur) in Verbindung mit der Unterdrückung redundanter Nack -Feedback der Empfängergruppe. Darüber hinaus kann Norm so konfiguriert werden, dass sie mit „stillen Empfängern“ arbeiten, die auf der Codierung des Paketlösches für die Bereitstellung von hoher Versicherung stützen und so nur als Rundfunkprotokoll wirken. Der FEC kann so konfiguriert werden, dass sie entweder reaktiv (mit Nackerempfängern) oder proaktiv (stille Empfänger) oder auf hybride Weise verwendet werden, die Kompromisse in Latenz- und Netzwerkaufwand ermöglicht.
Neben der Unterstützung von zuverlässigem Transport bietet Norm auch TCP-kompatibel Überlastungskontrolle sowie End-to-End Ablaufsteuerung. Im Gegensatz zu TCP, bei dem der ACK -Mechanismus für die Steuerung und Durchflussregelung der Stauung verwendet wird, verwendet die Norm für jeweils separate Mechanismen. Dies ermöglicht eine Vielzahl von Konfigurationen, um unterschiedliche Anforderungen an die Daten zur Anwendungsdaten zu erfüllen.
Norm unterstützt auch zusätzliche Signalmechanismen, die er erleichtern können Sitzung Steuerung, Anwendungssteuerung positiver Anerkennung und andere Funktionen zum Aufbau vollständiger Point-to-Point- und Gruppennetzwerkkommunikationsanwendungen, die sehr robust und effizient sind.
Obwohl Norm in erster Linie entwickelt wurde, um die Kommunikation von Multicast -Gruppen zu unterstützen, unterstützt sie auch Unicast (Punkt-zu-Punkt-) Datenübertragungen.
Hintergrund
Im TCP/IP -Netzwerkmodell ist die Transportschicht des Netzwerks (Layer 4) für den zuverlässigen Datentransport verantwortlich. Das TCP-Protokoll ist das Hauptmittel zur Gewährleistung eines zuverlässigen UNICAST-Transports (Punkt-zu-Punkt-Transport). TCP macht dies durch einen ACK -Mechanismus.
Mit dem ACK -Mechanismus werden Datenpakete nacheinander nummeriert, und der Absender sendet erst dann ein Paket in einer Sequenz, wenn es vom Empfänger eine Bestätigung (ACK) erhält, dass das vorherige Paket erfolgreich empfangen wurde. Wenn der Absender nach einem bestimmten Zeitraum keinen ACK erhält, wird das zugehörige Paket verwendet. Der Absender wird dies fortsetzen, bis er einen ACK erhält (obwohl der Absender über einen bestimmten Punkt hinausgeht, geht davon aus, dass die Verbindung verloren gegangen ist und die Sitzung stoppt). Dies ist locker analog zu einem menschlichen Zuhörer, der mit seinem Kopf nickt und in einem Einzelgespräch zwischen Personen "uh-huh" sagt. (Das Schwesterprotokoll von TCP, UDP, tut dies nicht. UDP sendet einfach Datenpakete über das Netzwerk in a Beste Anstrengung Art und Angenommen, die Pakete sind gut aufgenommen.)
Ein frühes Problem, das mit dem ACK -Mechanismus von TCP festgestellt wurde, war, dass es in großen Multicast -Gruppenkommunikation nicht gut funktionierte. In Multicast Group Communications werden Datenpakete gleichzeitig an eine Gruppe von Empfängern übertragen. In großen Multicast -Gruppen kann die Verwendung von ACKs „ACK -Implosionen“ erzeugen, bei denen eine große Anzahl gleichzeitiger ACKs den Absender überwältigen kann.[1] Dies ist locker analog zu einem großen Raum für menschliche Zuhörer, der mit dem Kopf nickt und "uh-huh" sagt, während ein Sprecher spricht.
Das Multicast -Verbreitungsprotokoll (MDP)[2] war ein erster Versuch, die Zuverlässigkeit zu gewährleisten und das Problem der ACK -Implosionen durch die Verwendung von Nacks anzugehen. MDP verwendete selektive negative Anerkennung (NACK), um die Zuverlässigkeit zu unterstützen. Darüber hinaus implementierte MDP probabilistische Techniken zur Unterdrückung redundanter Nacks in der Multicast -Gruppe (und damit Nacktross -Implosionen vermeiden).
MDP verwendete auch Paket-Level-Vorwärtsfehlerkorrekturcodierungskonzepte als Reparaturmechanismus. Codierte Paritätsreparaturpakete wurden im Allgemeinen als Antwort auf Reparaturanforderungen durch Empfänger gesendet. Auf diese Weise wurde keine zusätzlichen Protokollaufwand über selektive Wiedervermietungsmethoden hinzugefügt. Darüber hinaus ermöglichte MDP das Protokoll optional so konfiguriert, dass sie proaktive Reparaturpakete im Originaldatenübertragungsblock senden.
MDP war ein direkter Vorgänger der Norm, mit einem ersten IETF -Entwurf im November 1996 veröffentlicht.[3] Die National Aeronautics and Space Administration (NASA) übernahm MDP für zuverlässige Dateiübertragungen bei Weltraummissionen.[4]und die US -Armee verwendet in ihrer Force Battle Command Brigade und unter (FBCB2) -System für taktische Gruppennachrichten.[5]
Etwa zur gleichen Zeit wurden mehrere andere Ansätze für zuverlässige Multicast entwickelt.[6] Und im April 1999 garterte die IETF die zuverlässige Multicast Transport -Arbeitsgruppe (RMTWG), um den zuverlässigen Multicast -Transport zu standardisieren.[7]
Die RMTWG verfolgte die Strategie der Entwicklung von Bausteinen und Protokoll -Instanziationen. Diese Strategie hat ein Protokoll "Eingröße für alle" vermieden, das wiederum die große Anzahl von Anwendungen und Arten von Anwendungen berücksichtigen könnte, die zuverlässiger Multicast unterstützen könnten.
Bausteine wurden definiert als „eine Reihe von leicht trennbaren, grobkörnigen modularen Komponenten, die mehrere Protokolle sowie abstrakte APIs, die die Zugangsmethoden und deren Argumente eines Bausteins definieren, gemeinsam sind.[7] Zu den anfänglichen Bausteinen gehörten negative Anerkennung, Vorwärtsfehlerkorrektur, ein generischer Signalmechanismus für den Router -Assistent und den Transportschutz
Protokoll -Instanziationen wurden definiert als „Spezifikationen, die die notwendige Klebungslogik und die minimale zusätzliche Funktionalität definieren, die erforderlich ist, um ein Arbeitsprotokoll aus einem oder mehreren Bausteinen zu realisieren.“[7] Diese Spezifikationen würden auch eine abstrakte API umfassen, die die Schnittstelle zwischen der Protokollimplementierung und einer Anwendung definierte. Es wurden zwei Protokoll -Instantien ausgewählt:
- Ein Nackbasis-Protokoll
- Ein Asynchrone Layered Coding Protokoll
Im Juli 2005 wurden die Nack-basierten Protokollbausteine und die Protokoll-Instanziierung in RFC 3940 als „experimentell“ eingereicht, und im November 2009 wurde „Nack-oriented zuverlässige Multicast (NORMAST) -Protokoll“ in RFC 5740 zugelassen.[8]
Die RMTWG wurde im September 2013 abgeleitet.[9]
Norm architektonische Konstrukte
Die folgenden architektonischen Konstrukte sind in RFC 5740 Abschnitt 2, Architekturdefinition, definiert.[10]
Die Norm Botschaft ist das grundlegende normarchitektonische Konstrukt. Eine Normnachricht ist im Datenfeld eines UDP -Datagramms enthalten.
Eine Norm Objekt Bezieht sich auf eine der drei verschiedenen Arten von Massendaten, die in einer Normnachricht übertragen werden:
- NORM_OBJECT_DATA
- Norm_Object_file
- Norm_Object_stream
Norm_Object_data bezieht sich auf statische Inhalt des Computerspeicherdaten, während Norm_object_file auf Computerspeicherdateien bezieht. Beide Nachrichtentypen bieten einen zuverlässigen Transport zu endlichen Inhaltenblöcken. Es wird jedoch eine Unterscheidung getroffen, damit Empfänger feststellen können, welche Art von Speicher für den Inhalt empfangener Nachrichten zugewiesen werden soll.
Das Norm_Object_stream bezieht sich auf Streams (nicht finanz) des kontinuierlichen Dateninhalts. Norm unterstützt den zuverlässigen Transport von Streaming -Daten ähnlich der von TCP, wobei die NORM -Empfänger ohne Rücksicht auf den Zeitpunkt des Streams an der Rezeption von Stream -Inhalten teilnehmen können.
Eine Norm Sitzung Bezieht sich auf den Informationsaustausch unter zwei oder mehr Netzwerkhosts, die Norm verwenden. Typischerweise findet eine Norm-Sitzung mit vorbestimmter Bestimmung statt IP -Adressen und Portnummern, die normalerweise mit verbunden sind IP -Multicast -Gruppenadressen die vor der Sitzung bestimmt werden. Diese Adressen können unter Verwendung anderer Protokolle wie der bestimmt werden Sitzung Beschreibung Protokoll (SDP) [RFC 4566] oder der Sitzungsprotokoll (SAP) [RFC 2974]. Obwohl Norm speziell für die Kommunikation mit Multicast -Gruppen entwickelt wurde, unterstützt sie auch die Unicast -Kommunikation.
Eine grundlegende Annahme über eine Normsitzung ist, dass sie aus einem einzigen Sender besteht, der mit einer Gruppe von Empfängern kommuniziert. Mehrere Absender können in einer bestimmten Norm -Sitzung betrieben werden, obwohl jeder Empfänger für jeden Absender den Zustand beibehalten muss.
Eine Norm Knoten Bezieht sich auf einen einzelnen Knoten, der an einer Normsitzung teilnimmt. Jeder Knoten hat eine eindeutige Kennung. Wenn ein Knoten eine Normnachricht überträgt, wird diese Kennung als die festgestellt SCRECT_ID.
Eine Norm Beispiel Bezieht sich auf einen einzelnen Knoten im Kontext eines kontinuierlichen Segments einer Norm -Sitzung. Wenn sich ein Knoten einer Norm -Sitzung anschließt, verfügt er über eine eindeutige Knotenidentifikation sowie eine Instanzidentifikation. Wenn der Knoten die Sitzung aus irgendeinem Grund verlässt und später in die Sitzung zurückzuführen ist, bleibt die Knotenidentifikation gleich, aber die Instanzidentifikation ändert sich. Die aktuelle Instanz wird als die festgestellt Instance_id.
Normnachrichtsstruktur
Norm verfügt über zwei allgemeine Nachrichtenklassen, Absender- und Empfängernachrichten, die in RFC 5740 Abschnitt 4, NORM -Nachrichtenformate, definiert sind.[11] NORM -Absender -Nachrichtentypen sind: NORM_DATA, NORM_INFO und NORM_CMD. Norm Receiver -Nachrichtentypen sind: Norm_nack, Norm_ack und Norm_report.
Alle Normmeldungen bestehen aus einem obligatorischen gemeinsamen Header, einem Abschnitt mit Nachrichtentyp und einem Payload ( -Daten). Ein optionales Erweiterungsfeld, das die verwendete Fehlerkorrekturkodierung, den Stauungssteuerungsalgorithmus oder andere Sitzungsverwaltungsinformationen angibt, kann zwischen den Abschnitten Header und Nutzlast eingefügt werden.
| 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| Gemeinsame Nachrichtenüberschreitung | |||||||||||||||||||||||||||||||
| Meldungstyp Header | |||||||||||||||||||||||||||||||
| Optionale Headerverlängerungen | |||||||||||||||||||||||||||||||
| Nutzlast | |||||||||||||||||||||||||||||||
Norm Common Message Header
Alle Normmeldungen beginnen mit dem folgenden gemeinsamen Header, der in RFC 5740, Abschnitt 4.1, Norm Common Message Header und Erweiterung definiert ist.[12]
| 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| Ausführung | Typ | HDR_LEN | Reihenfolge | ||||||||||||||||||||||||||||
| SCRECT_ID | |||||||||||||||||||||||||||||||
- Version (4 Bit)
- Die Protokollversionsnummer.
- Typ (4 Bit)
- Der Norm -Nachrichtentyp (d. H. 1 = Norm_info, 2 = Norm_data, 3 = Norm_cmd, 4 = Norm_nack, 5 = Norm_ack, 6 = norm_report).
- HDR_LEN (8 Bit)
- Die Anzahl der 32-Bit-Wörter, die den Header-Teil der angegebenen Nachricht ausmachen. Dies wird verwendet, um die Zugabe von Header -Erweiterungen zu identifizieren. Wenn der Wert "hdr_len" größer ist als der Basiswert für den angegebenen Nachrichtentyp, impliziert er das Vorhandensein einer Header -Erweiterung.
- Sequenz (16 Bit)
- Dient zwei Zwecken (abhängig vom Nachrichtentyp):
- Ermöglicht Empfängern, eine Schätzung des Paketverlusts beizubehalten, um die Überlastungskontrolle zu erleichtern
- Unterstützt den Schutz von Nachrichten -Replay -Angriffen von Norm_nack oder Norm_NACK -Nachrichten.
- Source_ID (32 Bit)
- Die eindeutige Identifizierung des Knotens, der die Nachricht im Kontext einer bestimmten Normsitzung entstanden hat.
Norm_data Nachrichtentyp
Die in RFC 5740 Abschnitt 4.2.1 definierte NORM_DATA -Nachricht ist der am häufigsten von NORM -Absendern übertragene Nachrichtentyp.[13] NORM_DATA -Nachrichten tragen segmentierte Dateninhalte für norm_object_data, norm_object_file und norm_object_stream.
| 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| Ausführung | Typ | HDR_LEN | Reihenfolge | ||||||||||||||||||||||||||||
| SCRECT_ID | |||||||||||||||||||||||||||||||
| Instance_id | Grtt | Backoff | gSIZE | ||||||||||||||||||||||||||||
| Flaggen | fec_id | Object_transport_id | |||||||||||||||||||||||||||||
| fed_payload_id | |||||||||||||||||||||||||||||||
| Header_extensions (falls zutreffend) | |||||||||||||||||||||||||||||||
| payload_length (siehe Anmerkung 1) | payload_msg_start (siehe Anmerkung 1) | ||||||||||||||||||||||||||||||
| payload_offset (siehe Anmerkung 1) | |||||||||||||||||||||||||||||||
| payload_data | |||||||||||||||||||||||||||||||
- Instance_id (16 Bit)
- Eine eindeutige Identifizierung der aktuellen Instanz der Teilnahme an der Norm -Sitzung.
- Grtt (8 Bit)
- Die aktuelle Schätzung des Absenders zur Gruppenrundfahrtzeit.
- Backoff (4 Bit)
- Ein von Empfängern verwendeter Wert zur Bestimmung des maximalen Backoff-Timer-Werts bei der Verwendung von Timer-basierten Norm Nack-Rückkopplungsmechanismen.
- gSIZE (4 Bit)
- Die aktuelle Schätzung der Gruppengröße des Absenders.
- Flaggen (32 Bit)
- Binärflaggen liefern Informationen, die den Empfänger bei der angemessenen Bearbeitung der Nutzlast unterstützen.
- fec_id
- Die FEC -Codierungskennung. Dies wird im FEC Building Block -Dokument [RFC5052] beschrieben.
- Object_transport_id
- Ein von dem Absender an Norm -Objekte zugewiesener Wert, der übertragen wird, dass Empfänger für Übertragungen und Reparaturanforderungen verwendet werden. Es wird monotonisch inkrementell erhöht.
- fec_payload_id
- Eine Kennung für den angehängten Nutzlastinhalt von Norm_Data.
- Anmerkung 1
- payload_length, payload_msg und payload_offset beziehen sich nur auf norm_object_stream -Inhalt.
Norm_info Nachrichtentyp
NORM_INFO -Nachrichten, definiert in RFC 5740 Abschnitt 4.2.2, optional zulassen, Daten außerhalb des Bandes in Zusammenarbeit mit den Dateninhaltsobjekten gesendet werden.[14] Auf diese Weise können Empfänger die Art des übertragenen entsprechenden Inhalts bestimmen, was wiederum die Steuerung der Anwendungsebene über die Teilnahme des Empfängerknotens an der Sitzung ermöglicht.
Der Norm_info -Inhalt muss in den Nutzlastbereich einer einzelnen Normnachricht passen. Somit gilt es als atomar. Ein Beispiel für die Verwendung von Norm_info wäre das Senden von MIME-Informationen für den zugehörigen Normdateninhalt. Dies würde es Empfängern ermöglichen, Entscheidungen über ihre Teilnahme an der Sitzung zu treffen.
| 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| Ausführung | Typ | HDR_LEN | Reihenfolge | ||||||||||||||||||||||||||||
| SCRECT_ID | |||||||||||||||||||||||||||||||
| Instance_id | Grtt | Backoff | gSIZE | ||||||||||||||||||||||||||||
| Flaggen | fec_id | Object_transport_id | |||||||||||||||||||||||||||||
| Header_extensions (falls zutreffend) | |||||||||||||||||||||||||||||||
| payload_data
| |||||||||||||||||||||||||||||||
- Instance_id (16 Bit)
- Eine eindeutige Identifizierung der aktuellen Instanz der Teilnahme an der Norm -Sitzung.
- Grtt (8 Bit)
- Die aktuelle Schätzung des Absenders zur Gruppenrundfahrtzeit.
- Backoff (4 Bit)
- Ein von Empfängern verwendeter Wert zur Bestimmung des maximalen Backoff-Timer-Werts bei der Verwendung von Timer-basierten Norm Nack-Rückkopplungsmechanismen.
- gSIZE (4 Bit)
- Die aktuelle Schätzung der Gruppengröße des Absenders.
- Flaggen (32 Bit)
- Binärflaggen liefern Informationen, die den Empfänger bei der angemessenen Bearbeitung der Nutzlast unterstützen.
- fec_id
- Die FEC -Codierungskennung. Dies wird im FEC Building Block -Dokument [RFC5052] beschrieben.
- Object_transport_id
- Ein von dem Absender an Norm -Objekte zugewiesener Wert, der übertragen wird, dass Empfänger für Übertragungen und Reparaturanforderungen verwendet werden. Es wird monotonisch inkrementell erhöht.
Norm_cmd Nachrichtentyp
NORM_CMD -Nachrichten, die in RFC 5740 -Abschnitt 4.2.3 definiert sind, werden verwendet, um Normsitzungen zu verwalten.[15] Diese Nachrichten dienen dazu, das Timing von Roundtrips zu sammeln, Daten zu sammeln und zu senden, die sich auf die Stauungsregelung beziehen, Reparaturfenster synchronisieren und den Status eines Absenders melden. Es gibt einen Kernsatz von angegebenen und aufgezählten Norm_CMD-Nachrichten sowie einen Bereich, den andere verfügbare Typen für die Anwendungsspezifische Verwendung haben.
| 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| Ausführung | Typ | HDR_LEN | Reihenfolge | ||||||||||||||||||||||||||||
| SCRECT_ID | |||||||||||||||||||||||||||||||
| Instance_id | Grtt | zurück | gSIZE | ||||||||||||||||||||||||||||
| Flaggen | fec_id | Object_transport_id | |||||||||||||||||||||||||||||
| Untertyp | Norm_cmd Inhalt | ||||||||||||||||||||||||||||||
| Norm_cmd Inhalt
| |||||||||||||||||||||||||||||||
- Instance_id (16 Bit)
- Eine eindeutige Identifizierung der aktuellen Instanz der Teilnahme an der Norm -Sitzung.
- Grtt (8 Bit)
- Die aktuelle Schätzung des Absenders zur Gruppenrundfahrtzeit.
- Backoff (4 Bit)
- Ein von Empfängern verwendeter Wert zur Bestimmung des maximalen Backoff-Timer-Werts bei der Verwendung von Timer-basierten Norm Nack-Rückkopplungsmechanismen.
- gSIZE (4 Bit)
- Die aktuelle Schätzung der Gruppengröße des Absenders.
- Flaggen (32 Bit)
- Binärflaggen liefern Informationen, die den Empfänger bei der angemessenen Bearbeitung der Nutzlast unterstützen.
- fec_id
- Die FEC -Codierungskennung. Dies wird im FEC Building Block -Dokument [RFC5052] beschrieben.
- Object_transport_id
- Ein von dem Absender an NormObjects zugewiesener Wert wird übertragen, den Empfänger für Übertragungen und Reparaturanforderungen verwenden. Es wird monotonisch inkrementell erhöht.
- sub_type (8 Bit)
- Zeigt den folgenden Befehl an.
- Norm_cmd Inhalt
- Flush: Zeigt den vorübergehenden Übertragungsende des Absenders an. Kann auch optional verwendet werden, um eine positive Bestätigung des zuverlässigen Empfangs von einer Teilmenge von Empfängern zu sammeln.
- EOT: Zeigt ein dauerhaftes Ende der Übertragung an.
- Squelch: Zeigt das aktuelle Reparaturfenster des Absenders als Antwort auf Nacks außerhalb der Reichweite an
- CC: Wird für die GRTT -Messung und Sammlung von Überlastungskontroll -Feedback verwendet
- Reparatur_ADV: Wirft der aggregierte Reparatur-/Feedback -Zustand des Absenders für die Unterdrückung von Unicast -Feedback von Empfängern.
- ACK_REQ: Fordern Sie eine anwendungsdefinierte positive Bestätigung aus einer Liste von Empfängern an (optional).
- Anwendung: Wird für anwendungsdefinierte Zwecke verwendet, die die Datenübertragung vorübergehend vorab oder ergänzen (optional).
Norm_nack Nachrichtentyp
NORM_NACK -Nachrichten, die in RFC 5740 -Abschnitt 4.3.1 definiert sind, werden hauptsächlich für Empfänger verwendet, um Reparaturen von Absendungsinhalten anzufordern.[16] Darüber hinaus enthalten diese Nachrichten Felder, um den Absendern Informationen zur Erfassung und Überlastungskontrolle zur Verfügung zu stellen.
| 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| Ausführung | Typ | HDR_LEN | Reihenfolge | ||||||||||||||||||||||||||||
| SCRECT_ID | |||||||||||||||||||||||||||||||
| server_id | |||||||||||||||||||||||||||||||
| Instance_id | reserviert | ||||||||||||||||||||||||||||||
| grtt_response_sec | |||||||||||||||||||||||||||||||
| GRTT_Response_USEC | |||||||||||||||||||||||||||||||
| Header_extensions (falls zutreffend) | |||||||||||||||||||||||||||||||
| NACK_PAYLOAD
| |||||||||||||||||||||||||||||||
- server_id (32 Bit)
- Der Norm -Absender, zu dem die Norm_Nack -Nachricht bestimmt ist.
- Instance_id (16 Bit)
- Eine eindeutige Identifizierung der aktuellen Instanz der Teilnahme an der Norm -Sitzung.
- reserviert (16 Bit)
- Für den potenziellen zukünftigen Normnutzung
- GRTT_Response_sec (32 Bit)
- Eine angepasste Version des Zeitstempels aus der zuletzt empfangenen Norm_cmd (CC) -Meldung für den angegebenen Norm -Absender.
- GRTT_Response_usec (32 Bit)
- Eine angepasste Version des Zeitstempels aus der zuletzt empfangenen Norm_cmd (CC) -Meldung für den angegebenen Norm -Absender.
- NACK_PAYLOAD
- Die Reparaturbedürfnisse des Empfängers in Bezug auf den Norm -Sender, der vom Feld "server_id" angegeben ist.
NORM_ACK -Nachrichtentyp
Norm_ack-Nachrichten, die in RFC 5740 4.3.2 definiert sind, werden in erster Linie verwendet, um Stauungssteuerungsvorgänge und Timing-Messungen der Hin- und Rückfahrt zu unterstützen.[17]
| 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| Ausführung | Typ | HDR_LEN | Reihenfolge | ||||||||||||||||||||||||||||
| SCRECT_ID | |||||||||||||||||||||||||||||||
| server_id | |||||||||||||||||||||||||||||||
| Instance_id | ack_type | ACK_ID | |||||||||||||||||||||||||||||
| grtt_response_sec | |||||||||||||||||||||||||||||||
| GRTT_Response_USEC | |||||||||||||||||||||||||||||||
| Header_extensions (falls zutreffend) | |||||||||||||||||||||||||||||||
| ACK_PAYLOAD (falls zutreffend) | |||||||||||||||||||||||||||||||
- server_id (32 Bit)
- Der Norm -Absender, zu dem die Norm_ack -Nachricht bestimmt ist.
- Instance_id (16 Bit)
- Eine eindeutige Identifizierung der aktuellen Instanz der Teilnahme an der Norm -Sitzung.
- ACK_TYPE (8 Bit)
- Die Art der Norm_ack -Nachricht. Dies entspricht direkt dem Feld "ack_type" der NORM_CMD (ACK_REQ) -Meldung, für die diese Bestätigung gilt.
- ACK_ID (8 Bit)
- Eine Sequenznummer, sodass der Absender eine empfangene Norm_ack -Nachricht überprüfen kann, gilt tatsächlich für eine aktuelle Bestätigungsanforderung. Das Feld "ack_id" wird im Fall der Bestätigungsarten von Norm_ack (CC) und Norm_ack (Flush) nicht verwendet.
- GRTT_Response_sec (32 Bit)
- Eine angepasste Version des Zeitstempels aus der zuletzt empfangenen Norm_cmd (CC) -Meldung für den angegebenen Norm -Absender.
- GRTT_Response_usec (32 Bit)
- Eine angepasste Version des Zeitstempels aus der zuletzt empfangenen Norm_cmd (CC) -Meldung für den angegebenen Norm -Absender.
- ACK_PAYLOAD (falls zutreffend)
- Das Format "ack_payload" ist eine Funktion des "ack_type".
Norm_report Nachrichtentyp
Die in RFC 5740 Abschnitt 4.4.1 besprochene Norm_report -Nachricht ist eine optionale Nachricht.[18] Das Format ist derzeit undefiniert.
Norm -Header -Erweiterungen
Optionale Header-Erweiterungen, definiert in RFC 5740 Abschnitt 4.1, folgen dem gemeinsamen Header und dem meldungsspezifischen Header und gehen vor der Nutzlast (falls vorhanden).[19] Header -Erweiterungen enthalten typischerweise Informationen zu Basis -FEC, Überlastungskontrollvorgängen und anderen Sitzungen zur Sitzungverwaltung. Es gibt zwei Arten von Header-Erweiterungen: variable Länge und feste Länge.
| 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| Het ≤ 127 | Hel | Header -Erweiterungsinhalt | |||||||||||||||||||||||||||||
| Header -Erweiterungsinhalt
| |||||||||||||||||||||||||||||||
- Het (8 Bit)
- Der Header -Erweiterungstyp. Für Headerverlängerungen variabler Länge ein Wert zwischen 0 und 127 (inklusive).
- Hel (8 Bit)
- Die Header -Verlängerungslänge. Zeigt die Länge der gesamten Header -Erweiterung an.
- Header -Erweiterungsinhalt
- Variiert je nach Zweck.
| 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| Het ≥ 128 | reserviert | Header -Erweiterungsinhalt | |||||||||||||||||||||||||||||
- Het (8 Bit)
- Der Header -Erweiterungstyp. Für Headerverlängerungen mit fester Länge ein Wert zwischen 128 und 255 (inklusive).
- Reserviert (8 Bit)
- Reserviert für zukünftige Verwendung.
- Header -Erweiterungsinhalt (16 Bit)
- Variiert je nach Absicht.
Protokollbetrieb
Allgemeine Operationen
Der folgende allgemeine Norm -Protokoll -Betrieb ist in Abschnitt 5 RFC 5740 beschrieben, detaillierter Protokollbetrieb.[20]
1. Nach der Einrichtung einer Norm-Sitzung unterteilt ein Absender ein Normobjekt in eine Ordnungszahlen. Diese Segmente werden als Norm_Data -Nachrichten übertragen. Zusätzlich zu Dateninhalten sind Norm_Data -Nachrichten mit eindeutigen Kennungen und FEC -Kennungen gekennzeichnet. Der Absender kann außerdem außerhalb des Bandes Norm_info-Nachrichten senden, die dem Inhalt von NORM_DATA zugeordnet sind, mit denen Empfänger die Art des entsprechenden Inhalts bestimmen können, was wiederum die Steuerung des Empfängerknotens an der Sitzung ermöglicht.
Gleichzeitig überträgt der Absender regelmäßig Norm_cmd (CC) Nachrichten, um Feedback -Informationen zu sammeln, die für die Überlastungskontrolle und andere Sitzungsverwaltungsaktivitäten erforderlich sind.
2. Wenn Empfänger fehlende Inhalte von einem Absender erkennen, können sie versuchen, mit FEC -Mechanismen zu reparieren. Abgesehen von erfolgreichen Reparaturen senden die Empfänger Norm_nack Nachrichten an den Absender. Unter Verwendung der Ordnungszahlen-Sequenzinformationen geben die Empfänger fehlende Inhalte an.
3. Wenn der Absender Nacks empfängt, werden Reparaturanfragen zusammengefasst und entsprechende Reparaturen sendet, die mit den Ordinally-nummerierten Sequenzinformationen verbunden sind.
4. Wenn der Absender das Ende einer Sammlung von Reparaturanforderungen erreicht, überträgt er eine NORM_CMD -Nachricht (Flush), die das temporäre Ende der Übertragung angibt.
Im Kontext allgemeiner Operationen verfügt die Norm über spezifische Mechanismen, um die Sitzung der Sitzung, die Überlastungsregelung, die Durchflussregelung, die Zuverlässigkeit und das Nackmanagement zu beheben.
Sitzungskontrolle
Obwohl Norm nicht a ist Verbindungs orientiert Protokoll wie TCP hat es sowohl verbindungsorientierte als auch verbindungslose Eigenschaften.[21]
Im Gegensatz zum verbindungsorientierten TCP-Protokoll legt Norm keine Sitzung mit einem Setup-Mechanismus (d. H. Ein Drei-Wege-Handshake) fest. Vielmehr verwendet Norm vorgefertigte Portnummern und -adressen, die Sender und Empfänger kennen müssen. Auf diese Weise können Empfänger die laufenden Normsitzungen anschließen und eine schnelle Wiederaufnahme einer Sitzung nach einem Netzwerkausfall ermöglicht.
Gleichzeitig halten Norm-Absender und -Erempfänger den Zustand bei, um eine zuverlässige Übertragung sicherzustellen, daher ist die Norm nicht vollständig verbindungslos.
Eine Reihe von Sub-Typen von NORM_CMD-Nachrichten ist der Unterstützung von Sitzungssteuerungsprotokollen reserviert, die möglicherweise in Zukunft entwickelt werden.
Überlastungskontrolle
Norm verwendet ein TCP-freundlicher Überlastungskontrollschema, mit dem es die verfügbare Bandbreite mit TCP und anderen Transportprotokollen fair teilen kann.[22] Insbesondere verwendet das Stauungskontrollschema von Norm ein Ratenkontrollverfahren und ist eine Anpassung des in RFC4654 beschriebenen Protokollspezifikationsansatzes für Multicast-Überlastungskontrolle (TFMCC] -Protokollspezifikationsansatz. Es wurde gezeigt, dass dieser Ansatz gut mit TCP- und Multicast -Datenflüssen funktioniert.
Der TFMCC-Überlastungskontrollansatz ist ein Gleichungsansatz. Die Übertragungsraten von Absendern stützen sich auf die Sammlung von Paketverlustschätzungen und Rundfadenzeiten, die mit Norm_CMD (CC) -Meldungen gesammelt werden. Diese Informationen identifizieren Engpässe und passen die Absendungsrate an, um sie aufzunehmen.
Wie bei TCP wird das Norm -Überlastungskontrollschema angenommen, dass Paketverlust auf Pufferüberläufe zurückzuführen sind, und der Absender schlägt folglich die IT -Übertragungsrate zurück, wenn der Paketverlust ein bestimmtes Niveau erreicht. Dies kann zu Einschränkungen in drahtlosen Netzwerken führen, bei denen der Paketverlust häufig auf Bitfehler oder Streitigkeiten zurückzuführen ist.
Da der Norm -Rate -Kontrollmechanismus von seinen anderen Komponenten getrennt ist, z. B. Zuverlässigkeitsmechanismus, Durchflussregelmechanismus, kann er durch einen alternativen Algorithmus und geeignete Headerverlängerungen ersetzt werden.
Ablaufsteuerung
Norm verfügt über vier Optionen für die Durchflussregelung, mit denen der NORM -Absender die Übertragungsrate an NORM -Empfänger verwalten kann, um sicherzustellen, dass die Empfänger nicht überfordert sind.[23]
1. explizit Wasserzeichen. Mit dieser Option fordert der Absender eine positive Bestätigung von einem bestimmten Empfänger in Bezug auf die erfolgreiche Empfang eines bestimmten Punktes oder Wasserzeichens in der aktuellen Übertragung an. Wenn alle Empfänger den erfolgreichen Eingang des Wasserzeichens bestätigen, kann der Absender weiterhin neue Daten senden.
2. Implizite Wasserzeichen. Diese Option basiert auf einem mangelnden Reparaturanforderungen (Negativanerkennung) aus dem Empfängersatz. Der Absender verwendet das Norm_cmd (Flush), um Empfänger für die Reparaturen, die über das angegebene Wasserzeichen erforderlich sind, auf Nack zu bringen. Der Absender wartet dann, bis das Spülen vollständig abgeschlossen ist. Wenn es keine Nack -Aktivität gab, geht der Absender das abgeschlossene „Wasserzeichen“ an und kann weiterhin neue Daten senden.
3. Weiche Timer-basierte Durchflussregelung. Diese Option enthält Datenübertragungsdaten und Grenzwerte für das Reparaturfenster auf der Grundlage des Gruppenrundweg-Timings (GRTT) und der Nackaktivität. Es wird ein minimales, anpassungsfähiges Frastlimit festgelegt, wonach der Absender weiterhin neue Daten senden kann. Diese Zeitlimit basiert auf dem von Absendien geschätzten GRTT und mangelnder Nackaktivität.
4. Ziele Deaktivierung. Diese Option deaktiviert absichtlich die Flusssteuerungsmechanismen und ermöglicht es der Anwendung, die Übertragung mit neu ergriffenen Daten auf beste Anstrengung voranzutreiben.
Verlässlichkeit
Norm sorgt für einen zuverlässigen Transport durch die Verwendung von zwei Vorwärtsfehlerkorrektur Codierungsschemata: Systematische Codes und nicht systematische Codes. Diese werden in RFC 5740 Abschnitt 2, Architekturdefinition, erörtert:[24]
Mit systematischen Codes überträgt der Absender Inhaltblöcke, gefolgt von FEC -Blöcken.
Mit nicht-systematischen Codes codiert der Absender vor der Übertragung den Inhalt mit FEC.
Beide FEC -Codierungsschemata können entweder reaktiv oder proaktiv verwendet werden. In beiden Fällen kann die Reparatur auf FEC-basierte Reparatur betroffen sein, wodurch Empfänger Pakete repariert werden können und dadurch das Maß an Reparaturanforderungen und Reparaturübertragungen reduziert werden.
Skalierbarkeit und Nackmanagement
Nack-orientierte Multicast-Kommunikation sind anfällig für Nacktross-Implosionen. Wenn eine große Anzahl von Empfängern gleichzeitig Nack, könnte dies sowohl den Absender als auch das gesamte Netzwerk überwältigen. Norm verwendet einen Nack -Unterdrückungsmechanismus, der in RFC 5740, Abschnitt 5.3, Empfänger -Nackverfahren, erörtert wird, um Nack -Implosionen zu verhindern.[25]
Wenn ein Empfänger feststellt, dass es Daten bei den Normübertragungen eines Absenders fehlt, initiiert er das Nack -Verfahren:
- Es besteht die Annahme, dass ein oder mehrere andere Empfänger dieselben Daten verpasst haben und dass ein Nack möglicherweise bereits an den Absender gesendet wurde.
- Der Empfänger fährt in eine Holdoff -Periode ein, die auf einem zufälligen Backoff -Algorithmus basiert. Die Dauer dieser Zeitüberschreitung wird durch den im Multicast Nack Building Block [RFC5401] beschriebenen "Randombackoff" seiner übertragenen Nachrichten.
- Während der Holdoff -Zeit empfängt und bewertet der Empfänger Reparaturnachrichten vom Absender weiter und unterdrückt seinen eigenen Nack.
- Wenn der Empfänger am Ende des Holdoff -Zeitraums keine ausreichenden Reparaturinformationen erhalten hat, wird der Nack initiiert.
- Wenn die Norm -Sitzung in einer Multicast -Routing -Umgebung stattfindet, wird der Nack sowohl an den Absender als auch an alle anderen Knoten im Netzwerk übertragen.
- Wenn die Norm-Sitzung nicht in einer Multicast-Routing-Umgebung stattfindet, wird der Nack an den Absender übertragen, und der Absender setzt sie sofort an alle anderen Knoten im Netzwerk weiter.
Der Nack -Unterdrückungsmechanismus von Norm in Kombination mit seinem FEC -Mechanismus ermöglicht es den Norm -Multicast -Gruppen, auf sehr große Gruppengrößen zu skalieren und gleichzeitig die Zuverlässigkeit aufrechtzuerhalten.
Referenzimplementierung
Das Labor für Marineforschung der Vereinigten Staaten behält eine frei verfügbare Referenzimplementierung des Norm-Protokolls auf GitHub. Dies umfasst Quellcode, einen Entwicklerhandbuch und ein Benutzerhandbuch.
Normative RFC -Dokumente
- RFC 1112 - Host -Erweiterungen für IP Multicasting, August 1989
- RFC 2357 - IETF -Kriterien zur Bewertung zuverlässiger Multicast -Transport- und Anwendungsprotokolle, Juni 1998
- RFC 2974 - Sitzungsprotokoll, Oktober 2000
- RFC 3048-Zuverlässige Multicast-Transportbaubausteine für Eins-zu-Viele-Bulk-Datenübertragung, Januar 2001
- RFC 3269 - Autorenrichtlinien für zuverlässige Multicast Transport (RMT) Bausteine und Protokoll -Instantiationsdokumente, April 2002
- RFC 3453 - Die Verwendung der Vorwärtsfehlerkorrektur (FEC) in zuverlässigem Multicast, Dezember 2002
- RFC 3547 - Die Gruppendomäne der Interpretation, Juli 2003
- RFC 3550 - RTP: Ein Transportprotokoll für Echtzeitanwendungen, Juli 2003
- RFC 3830 - Mikey: Multimedia Internet Keying, August 2004
- RFC 3940-Negativverkleidung (NACK) -oriented zuverlässiges Multicast (Norm) -Protokoll, November 2004
- RFC 4301 - Sicherheitsarchitektur für das Internet -Protokoll, Dezember 2005
- RFC 4303 - IP -Einkapselung der Sicherheitsnutzlast (ESP), Dezember 2005
- RFC 4535 - GSAKMP: Group Secure Association Key Management Protocol, Juni 2006
- RFC 4566 - SDP: Sitzungsbeschreibung Protokoll, Juli 2006
- RFC 4607 - Quellspezifischer Multicast für IP, August 2006
- RFC 4654 - TCP -freundlich
- RFC 5052 - Baustein für Fehlerkorrekturen (FEC), August 2007
- RFC 5401 - Multicast -Bausteine (Multicast Negative -OcePnowLidging (Negative ", November 2008, November 2008
- RFC 5445 - FEC -Schemata für die Vorwärtsfehlerkorrektur (FEC), März 2009
- RFC 5740 - Nack -orientiertes zuverlässiges Multicast (Norm) -Vertransportprotokoll, November 2009
Siehe auch
Verweise
- ^ P.B. Danzig (Januar 1994). "Durchflussregelung für begrenzte Puffer Multicast". IEEE -Transaktionen auf Software -Engineering. 20 (1): 1–12. doi:10.1109/32.263751.
- ^ J.P. Macker; P.B. Adamson (1999). "Das Multicast -Disseminationsprotokoll (MDP) -Toolkit". IEEE Militärkommunikation. 1: 626–630. doi:10.1109/milcom.1999.822759.
- ^ J. Macker; W. Dang (November 1996). Das Multicast -Verbreitungsprotokoll (MDP) (Technischer Bericht). Ietf.
- ^ J. Rash; E. criscuolo; K. Hogie; R. Parise; J. Hennessy (Januar 2002). MDP: Zuverlässige Dateiübertragung für Speicherplatzmissionen (Technischer Bericht). NASA.
- ^ J.P. Macker; P.B. Adamson (Dezember 2010). Zuverlässige Nachrichten für die taktische Gruppenkommunikation. Militärkommunikationskonferenz 2010. doi:10.1109/milcom.2010.5680397.
- ^ Diot, C.; Dabbous, W.; Crowcroft, J. (April 1997). "Multipoint -Kommunikation: Eine Übersicht über Protokolle, Funktionen und Mechanismen" (PDF). IEEE Journal über ausgewählte Bereiche in Kommunikation. 15 (3): 277–290. doi:10.1109/49.564128.
- ^ a b c "IETF zuverlässige Multicast -Arbeitsgruppencharta". Abgerufen 22. Februar, 2021.
- ^ "IETF zuverlässige Multicast -Arbeitsgruppendokumente".
- ^ "IETF zuverlässige Multicast -Arbeitsgruppengeschichte". Abgerufen 22. Februar, 2021.
- ^ RFC 5740, Abschnitt 2, Architekturdefinition
- ^ RFC 5740, Abschnitt 4, Nachrichtenformate
- ^ RFC 5740, Abschnitt 4.1, Norm Common Message Header und Erweiterungen
- ^ RFC 5740, Abschnitt 4.2.1, Norm_Data -Nachricht
- ^ RFC 5740, Abschnitt 4.2.2, Norm_info -Nachricht
- ^ RFC 5740, Abschnitt 4.2.3, NORM_CMD -Nachricht
- ^ RFC 5740, Abschnitt 4.3.1, Norm_nack Nachricht
- ^ RFC 5740, Abschnitt 4.3.2, Norm_ack -Nachricht
- ^ RFC 5740, Abschnitt 4.4.1, Norm_report -Nachricht
- ^ RFC 5740, Abschnitt 4.1, Architekturdefinition
- ^ RFC 5740, Abschnitt 5, detaillierter Protokollbetrieb
- ^ J.P. Macker; P.B. Adamson (Dezember 2010). Zuverlässige Nachrichten für die taktische Gruppenkommunikation. Militärkommunikationskonferenz 2010. doi:10.1109/milcom.2010.5680397.
- ^ J.P. Macker; P.B. Adamson (Dezember 2010). Zuverlässige Nachrichten für die taktische Gruppenkommunikation. Militärkommunikationskonferenz 2010. doi:10.1109/milcom.2010.5680397.
- ^ J.P. Macker; P.B. Adamson (Dezember 2010). Zuverlässige Nachrichten für die taktische Gruppenkommunikation. Militärkommunikationskonferenz 2010. doi:10.1109/milcom.2010.5680397.
- ^ RFC 5740, Abschnitt 2, Architekturdefinition
- ^ RFC 5740, Abschnitt 5.3, Empfänger Nack -Verfahren
Weitere Lektüre
- D. Clark, D. Tennenhouse, „Architekturale Überlegungen für eine neue Generation von Protokollen“. Proc. ACM Sigcomm, September 1990.
- S. Floyd und V. Jacobson, "Zufällige frühe Erkennungs -Gateways für die Vermeidung von Staus", IEEE/ACM -Transaktionen zum Networking, V.1 N.4, August 1993.
- S. Pingali, D. Towsley, J. Kurose. "Ein Vergleich von von Absendern initiierten und von Empfänger initiierten zuverlässigen Multicast-Protokollen". Proc. Infocom, San Francisco, CA, Oktober 1993.
- S. Floyd, V. Jacobson, S. McCanne, C. Liu und L. Zhang. „Ein zuverlässiger Multicast -Rahmen für leichte Sitzungen und Rahmen von Anwendungsebene“, Proc. ACMSIGCOMM, August 1995.
- J. Macker, "Zuverlässiger Multicast-Transport und integrierter Löschungsbasis-Vorwärtsfehlerkorrektur", Proc. IEEE MILCOM 97, Oktober 1997.
- A. Mankin, A. Romanow, S. Bradner, V. Paxson, „IETF -Kriterien zur Bewertung zuverlässiger Multicast -Transport- und Anwendungsprotokolle“, RFC 2357, Juni 1998.
- D. Delucia, K. Obraczka, "Überlastungskontrollleistung eines zuverlässigen Multicast -Protokolls", Proc. IEEE ICNP 98, August 1998.
- D. Gosssink, J. Macker, "Zuverlässige Multicast- und Integrierte Paritätsübertragung mit Kanalschätzung", IEEE Globecom 98, Oktober 1998.
- B. Whetton und J. Conlan, "Ein ratenbasiertes Überlastungskontrollschema für zuverlässige Multicast", Technischer Bericht, Globalcast Communication, Oktober 1998.