Protkolle: Entstehung und Standarisieung

Ein Protokoll im allgemeinen Sinn bedient für Steuerung von Abläufen und die Handlung des anderen zu interpretieren, indem man sich auf einem gemeinsamen Satz von Regeln verständigt, die allgemein bekannt und unabhängig von nationalen Gebräuchen. Z.B beim diplomatischen Protokoll wird vor dem Besuch des Staatgasts der Ablauf des Treffens festgelegt, wie das Thema, die Sprache der Kommunikation und der Einsatz des Übersetzers usw. So lässt sich  beispielsweise die unnötige Zeitverlust oder Irrtümer der Sprachbarrieren vermeiden.

In der gleiche Weise spielt ein Protokoll bei Computer gleiche Rolle. So können Computer-Anwendungen ohne Missverständnisse kommunizieren, da diese Regeln die Nachrichtenaustausch zwischen Partner koordinieren und dadurch effizient machen. Aber in der Regel ist notwendig, beide Partner  über dasselbe Protokoll zu verfügen, denn sonst werden beide Seiten nicht wissen, wie die Datenaustausch stattfindet. Viele Informationen werden zwischen Datenverarbeitungsanlagen  mit den Protokollen vereinbart beispielweise : Größe der Daten, Codierung der Daten, Art der Übertragung, Sender, Empfänger darüber hinaus die beteiligte Protokolle.

Abbildung 1: Der Aufbau eines IPv4-Pakets (Datagramm) wird in RFC 791 (Kurs: Perl und CGI, kein Datum)

Weil die Kommunikation zwischen Datenverarbeitungsanlagen ziemlich komplex ist, ist es sinnvoll, mehrere Datenübertragungsprotokolle, die die unterschiedliche Aufgaben übernehmen, gleichzeitig zu nutzen. Diese arbeiten in Form von Protokolleschichten zusammen, um eine Dienstleistung für Benutzer zu erbringen. Die Protokolle höher Sichten benutzen Dienste von Protokolle  tiefer Sichten, sodass diese Protokolleeinheiten einen Protokollstapel wie DoD-Referenzmodell oder der Nachfolger ISO- Referenzmodell zusammenbilden.

1.1.                    Standarisierung der Protokolle - Request for Comments

Eine wichtige Rolle bei Entstehung und Entwicklung der Protokolle spielte die sogenannte RFC-Dokumente. In homogenen Netzwerken legt ein einzelner Computerhersteller den Satz der Kommunikationsregeln fest. Diese sind stärk abhängig von Betriebssystems und der Hardware-Architektur des Herstellers. Daher lässt sich die Nutzer anderer Netzwerk-Herstellern zusammen nicht kommunizieren. Aus diesem Grund brauchte man eine offenen Protokollspezifikation zu schaffen, die jedem Hersteller freigestellt ist, Protokolle zu entwickeln, indem diese Protokolle für jedem verfügbar ist und gemeinschaftlich entwickelt und geändert aber nicht für einzelnen Hersteller unterworfen werden.  Diese offene Natur dieser Protokollentwicklung verlangt natürlicherweise einen offenen Standardisierungsrozess. Dementsprechend wurde April 1969  diesen Prozess der Standarisierung als RFC (Request for Comments) von der Internet Engineering Task Force (IETF) und die  Internet Society (ISOC) veröffentlicht. Steve Crocker, Autor des ersten RFC, begründete diese Form damit, dass die Beteiligten nur Netzwerk-Hersteller oder Doktoranden ohne jede Autorität waren. (Hein, Entwicklung der TCP/IP Protokolle, 2006)

Wenn ein RFC-Dokument veröffentlicht, weist man ihm eine RFC-Nummer zu. So werden RFCs durchlaufend nummeriert.

RFC-Editor prüft die Dokumente in verschiedene Stufen, die man als maturrity levels bezeichnet. Diese Stufen teilen sich in der Entwicklung, Testung und Akzeptanz.

Maturity Level	Bedeutung
Proposed Standard (PS)	Diese Stufe dauert mindestens 6 Monate und erfordert zwei unabhängige Implementierungen.
Draft Standard (DS)	Diese Stufe dauert mindestens 4 Monate mit Demonstrationen und einem Erfahrungsbericht mit mindestens zwei unabhängigen Implementierungen.
Standard (S oder STD)	Das RFC ist zum offiziellen Standard erhoben. Internet-Standards erhalten neben der RFC-Nummer eine so genannte STD-Nummer (z.b. Internet Protocol, RFC791, STD-5)

Jeder RFC besitzt einen Status für die Gültigkeit. Hier sind Beispiele: (Santifaller, 1998) (Hempel, 2013)

Status	Bedeutung
Requird	Muss bei allen TCP/IP-basierten Hosts und Gateways implementiert werden.
Recommended	Diese Stufe dauert mindestens 4 Monate mit Demonstrationen und einem Erfahrungsbericht mit mindestens zwei unabhängigen Implementierungen.
Elective	Die Implementierung ist optional. Der Anwendung wurde zugestimmt, ist aber nicht erforderlich
Limited Use	Nicht für die generelle Nutzung gedacht.
Not Recommended	Nicht zur Implementierung empfohlen