Tcp/ip

Grundlagen

Was ist ein Rechnernetz?

Diese Frage habe ich mir auch längere Zeit gestellt. Die Literatur äußert sich hierzu leider auch nicht so ganz klar. Tanenbaum "definiert" ein Rechnernetz in [Ta96] wie folgt:

"Das ganze Buch hindurch wird der Begriff Rechnernetze für mehrere miteinander verbundene autonome Computer verwendet. Zwei Computer gelten als miteinander verbunden, wenn sie Informationen austauschen können. Die Verbindung muß nicht aus einem Kupferkabel bestehen - es können auch Lichtwellenleiter, Mikrowellen oder Kommunikationssatelliten benutzt werden. Die Vorgabe, daß die Computer autonom sein müssen schließt Systeme, bei denen ein eindeutiges Master/Slave-Verhältnis herrscht, von vornherein aus unserer Definition aus. Kann ein Computer einen anderen beliebig ein- oder ausschalten oder steuern, besteht keine Unabhängigkeit. Ein System mit einer Steuereinheit als Master und vielen Slaves ist kein Netz, ebensowenig wie ein Großrechner mit entfernten Druckern und Terminals."

Nach dieser Definition ist ein Netz, das aus einer Anzahl von Java-Rechnern (oder sind es doch nur Terminals) besteht kein Rechnernetz. Die Java- Rechner müssen ihr System erst aus dem Netz laden, bevor mit ihnen "autonom" gearbeitet werden kann. Die Frage ist hier zusätzlich: arbeiten Java-Rechner wirklich autonom? Deshalb möchte ich noch eine allgemeinere "Definition" eines Rechnernetzes aus [Co98] geben:

"Das alte Modell, bei dem ein Großrechner den gesamten Rechenaufwand eines Unternehmens bewältigte, wurde durch eines ersetzt, bei dem eine große Anzahl einzelner miteinander verbundener Rechner die Arbeit übernimmt. Ein solches System nennt man Rechnernetz."

Protokolle, Protokollhierarchien

Protokolle sind Regeln, die den Nachrichtenaustausch - oder allgemeiner das Verhalten - zwischen (Kommunikations)Partnern regeln ("Protocols are formal rules of behaviour"). Die Verletzung eines vereinbarten Protokolls erschwert die Kommunikation oder macht sie sogar gänzlich unmöglich. Ein Beispiel für ein Protokoll "aus dem täglichen Leben" ist z.B. der Funkverkehr: Die Kommunikationspartner bestätigen den Empfang einer Nachricht mit Roger und leiten einen Wechsel der Sprechrichtung mit Over ein. Beendet wird die Verbindung schließlich mit Over and out. Ähnliche Protokolle werden auch beim Datenaustausch zwischen verschiedenen Computern benötigt - auch wenn hier die Komplexität der Anforderungen etwas höher ist. Aufgrund dieser höheren Komplexität werden viele Aufgabe nicht von einem einzigen Protokoll abgewickelt. In der Regel kommen eine ganze Reihe von Protokollen, mit verschiedenen Teilaufgaben, zum Einsatz. Diese Protokolle sind dann in Form von Protokollschichten mit jeweils unterschiedlichen Funktionen angeordnet.

Anordnung von Protokollen zu einem Protokollstapel.

Eine kurze Geschichte des Internet

From small things, big things sometimes come (Tittel E., Robbins M.) Gegen Ende der sechziger Jahre, als der "kalte Krieg" seinen Höhepunkt erlangte, wurde vom US-Verteidigungsministerium (Department of Defence - DoD) eine Netzwerktechnologie gefordert, die in einem hohen Maß gegenüber Ausfällen sicher ist. Das Netz sollte dazu in der Lage sein, auch im Falle eines Atomkrieges weiter zu operieren. Eine Datenübermittlung über Telefonleitungen war zu diesem Zweck nicht geeignet, da diese gegenüber Ausfällen zu verletzlich waren (sind). Aus diesem Grund beauftragte das US-Verteidigungsministerium die Advanced Research Projects Agency (ARPA) mit der Entwicklung einer zuverlässigen Netztechnologie. Die ARPA wurde 1957 als Reaktion auf den Start des Sputniks durch die UdSSR gegründet. Die ARPA hatte die Aufgabe Technologien zu entwickeln, die für das Militär von Nutzen sind. Zwischenzeitlich wurde die ARPA in Defense Advanced Research Projects Agency (DARPA) umbenannt, da ihre Interessen primär militärischen Zwecken dienten. Die ARPA war keine Organisation, die Wissenschaftler und Forscher beschäftigte, sondern verteilte Aufträge an Universitäten und Forschungsinstitute.

Um die geforderte Zuverlässigkeit des Netzes zu erreichen, fiel die Wahl darauf, das Netz als ein paketvermitteltes Netz (packet-switched network) zu gestalten. Bei der Paketvermittlung werden zwei Partner während der Kommunikation nur virtuell miteinander verbunden. Die zu übertragenden Daten werden vom Absender in Stücke variabler oder fester Länge zerlegt und über die virtuelle Verbindung übertragen; vom Empfänger werden diese Stücke nach dem Eintreffen wieder zusammengesetzt. Im Gegensatz dazu werden bei der Leitungsvermittlung (circuit switching) für die Dauer der Datenübertragung die Kommunikationspartner fest miteinander verbunden. Ende 1969 wurde von der University of California Los Angeles (UCLA), der University of California Santa Barbara (UCSB), dem Stanford Research Institute (SRI) und der University of Utah ein experimentelles Netz, das ARPANET, mit vier Knoten in Betrieb genommen. Diese vier Universitäten wurden von der (D)ARPA gewählt, da sie bereits eine große Anzahl von ARPA-Verträgen hatten. Das ARPA-Netz wuchs rasant (siehe Abbildung) und überspannte bald ein großes Gebiet der Vereinigten Staaten

Wachstum des ARPANET a)Dezember 1969 b)July 1970 c)März 1971 d)April 1971 e)September 1972.(Quelle: A.S. Tanenbaum: Computernetworks ) Mit der Zeit und dem Wachstum des ARPANET wurde klar, daß die bis dahin gewählten Protokolle nicht mehr für den Betrieb eines größeren Netzes, das auch mehrere (Teil)Netze miteinander verband, geeignet war. Aus diesem Grund wurden schließlich weitere Forschungsarbeiten initiiert, die 1974 zur Entwicklung der TCP/IP-Protokolle bzw. des TCP/IP-Modells führten. TCP/IP wurde mit mit der Zielsetzung entwickelt, mehrere verschiedenartige Netze zur Datenübertragung miteinander zu verbinden. Um die Einbindung der TCP/IP-Protokolle in das ARPANET zu forcieren beauftragte die (D)ARPA die Firma Bolt, Beranek & Newman (BBN) und die University of California at Berkeley zur Integration von TCP/IP in Berkeley UNIX. Dies bildete auch den Grundstein des Erfolges von TCP/IP in der UNIX-Welt. Im Jahr 1983 wurde das ARPANET schließlich von der Defence Communications Agency (DCA), welche die Verwaltung des ARPANET von der (D)ARPA übernahm, aufgeteilt. Der militärische Teil des ARPANET, wurde in ein separates Teilnetz, das MILNET, abgetrennt, das durch streng kontrollierte Gateways vom Rest des ARPANET - dem Forschungsteil - separiert wurde. Nachdem TCP/IP das einzige offizielle Protokoll des ARPANET wurde, nahm die Zahl der angeschlossenen Netze und Hosts rapide zu. Das ARPANET wurde von Entwicklungen, die es selber hervorgebracht hatte, überrannt. Das ARPANET in seiner ursprünglichen Form existiert heute nicht mehr, das MILNET ist aber noch in Betrieb. (Zum Wachstum des Internet in Deutschland siehe: http://www.nic.de/Netcount/netStatHosts.html) Die Sammlung von Netzen, die das ARPANET darstellte, wurde zunehmend als Netzverbund betrachtet. Dieser Netzverbund wird heute allgemein als das Internet bezeichnet. Der Leim, der das Internet zusammenhält, sind die TCP/IP-Protokolle.

RFCs

Eine wichtige Rolle bei der Entstehung und Entwicklung des Internet spielen die sogenannten RFCs - Request for Comments. RFCs sind Dokumente, in denen die Standards für TCP/IP bzw. das Internet veröffentlicht werden. Einige RFCs beschreiben Dienste und Protokolle sowie deren Implementierung, andere fassen Regeln und Grundsätze (policies) zusammen. Standards für TCP/IP werden immer als RFCs veröffentlicht, aber nicht alle RFCs beschreiben Standards (siehe z.B. RFC1180 - A TCP/IP Tutorial, RFC527 - ARPAWOCKY, RFC968 - 'Twas the Night Before Start-up etc.) Die Standards für TCP/IP werden im wesentlichen nicht durch ein Komitee entwickelt, sondern durch Diskussion und Konsens beschlossen. Jeder hat die Möglichkeit ein Dokument als RFC zu veröffentlichen und so zur Diskussion zu stellen. Ist ein Dokument veröffentlicht, wird ihm eine RFC- Nummer zugewiesen. Die Dokumente werden von einer Arbeitsgruppe und/oder dem RFC-Editor geprüft. Dabei durchläuft das Dokument verschiedene Stufen, die Stufen der Entwicklung, Testung und Akzeptanz. Die Stufen bilden den sogenannten Standards Process. Die Stufen werden formal als maturity levels (Reifestufen) bezeichnet.

Maturity Level
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 midestens zwei unabhängigen Implementierungen.
Standard (S oder STD)	Das RFC ist zum offiziellen Standard erhoben. Internet-Standards erhalten neben der RFC- Nummer eine sogenannte STD-Nummer (z.B. Internet Protocol, RFC791, STD-5).

Zusätzlich zu seiner Stufe bekommt ein RFC einen Status

Status
Required	Muß bei allen TCP/IP-basierten Hosts und Gateways implementiert werden.
Recommended	Es wird empfohlen, daß alle TCP/IP-basierten Hosts und Gateways die Spezifikationen des RFCs implementieren. Diese RFCs werden üblicherweise auch immer implementiert.
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.

Ein RFC, das einmal veröffentlicht ist,wird nie verändert oder aktualisiert. Es kann nur durch ein neues RFC ersetzt werden. Bei einer Ersetzung wird das alte RFC mit der Bezeichnung "Obsoleted by RFC xxx" gekennzeichnet, das neue RFC beinhaltet einen Hinweis "Obsolets RFC xxx" auf das alte RFC. Korrekturen an einem RFC werden durch "Updates RFC xxx" und "Updated by RFC xxx" gekennzeichnet. Einige RFCs beschreiben Protokolle, die durch bessere ersetzt wurden, diese RFCs werden durch die Bezeichnung "historic" gekennzeichnet. Ein entsprechender Standard erhält den Status "not recommended". RFCs, die sich in einer experimentellen Phase der Entwicklung befinden werden mit der Bezeichnung "experimental" versehen. Protokolle, die von anderen Organisationen oder von Firmen entwickelt wurden und von Interesse für das Internet sind werden zum Teil auch in RFCs veröffentlicht mit den Bezeichnungen "informational" oder "best current practice". Das 'System' der RFCs leistet einen wesentlichen Beitrag zum Erfolg von TCP/IP und dem Internet. In der Referenzliste findet sich eine Angaben zu Quellen, bei denen die RFCs bezogen werden können. Anm.: Wer weitere Quellen zur Geschichte des Internet sucht, wird hier fündig:

Internet Society - ISOC: History of the Internet

Musch J.: Die Geschichte des Netzes: ein historischer Abriß

Hauben M.: Behind the Net: The Untold History of the ARPANET and Computer Science

Hauben R.: The Birth and Development of the ARPANET

w3history: Die Geschichte des World Wide Web

Referenzmodelle

Das OSI-Referenzmodell

Das Open Systems Interconnection (OSI)-Referenzmodell ist ein Modell, daß auf einem Vorschlag der International Standards Organisation (ISO) basiert. Der Aufbau des OSI-Modells ist in der folgenden Abbildung dargestellt.

OSI-Referenzmodell

Das Modell dient derzeit allgemein als Rahmen zur Beschreibung von Protokollcharakteristika und -funktionen (Ta96). Das OSI-Modell (die offizielle Bezeichnung lautet ISO-OSI-Referenzmodell) besteht aus sieben Schichten. Die Schichtung beruht auf dem Prinzip, daß eine Schicht der jeweils über ihr angeordneten Schicht bestimmte Dienstleistungen anbietet. Das OSI-Modell ist keine Netzarchitektur, da die Protokolle und Dienste der einzelnen Schichten vom Modell nicht definiert werden. Das Modell beschreibt lediglich, welche Aufgaben die Schichten erledigen sollen. Die folgenden Prinzipien haben zur Siebenschichtigkeit des OSI-Modells geführt (Ta96): Eine neue Schicht sollte dort entstehen, wo ein neuer Abstraktionsgrad benötigt wird. Jede Schicht sollte eine genau definiert Funktion erfüllen. Bei der Funktionswahl sollte die Definition international genormter Protokolle berücksichtigt werden. Die Grenzen zwischen den einzelnen Schichten sollten so gewählt werden, daß der Informationsfluß über die Schnittstellen möglichst gering ist. Die Anzahl der Schichten sollte so groß sein, daß keine Notwendigkeit besteht, verschiedene Funktionen auf eine Schicht zu packen, aber so klein, daß die gesamte Architektur nicht unhandlich wird.

Aufgaben der Schichten OSI

Den Schichten im OSI-Modell sind die folgenden Aufgaben zugeordnet:

Anwendungsschicht (application layer)

Die Anwendungsschicht enthält eine große Zahl häufig benötigter Protokolle, die einzelne Programme zur Erbringung ihrer Dienste definiert haben. Auf der Anwendungsschicht finden sich z.B. die Protokolle für die Dienste ftp, telnet, mail etc.

Darstellungsschicht (presentation layer)

Die Darstellungsschicht regelt die Darstellung der Übertragungsdaten in einer von der darüber liegenden Ebene unabhängigen Form. Computersysteme verwenden z.B. oft verschiedene Codierungen für Zeichenketten (z.B. ASCII, Unicode), Zahlen usw. Damit diese Daten zwischen den Systemen ausgetauscht werden können, kodiert die Darstellungsschicht die Daten auf eine standardisierte und vereinbarte Weise.

Sitzungsschicht (session layer)

Die Sitzungsschicht (oft auch Verbindungsschicht oder Kommunikationssteuerschicht genannt) ermöglicht den Verbindungsauf- und abbau. Von der Sitzungsschicht wird der Austausch von Nachrichten auf der Transportverbindung geregelt. Sitzungen können z.B. ermöglichen, ob der Transfer gleichzeitig in zwei oder nur eine Richtung erfolgen kann. Kann der Transfer jeweils in nur eine Richtung stattfinden, regelt die Sitzungsschicht, welcher der Kommunikationspartner jeweils an die Reihe kommt.

Transportschicht (transport layer)

Die Transportschicht übernimmt den Transport von Nachrichten zwischen den Kommunikationspartnern. Die Transportschicht hat die grundlegende Aufgaben, den Datenfluß zu steuern und die Unverfälschtheit der Daten sicherzustellen. Beispiele für Transportprotokolle sind TCP und UDP.

Netzwerkschicht (network layer)

Die Netzwerkschicht (Vermittlungsschicht) hat die Hauptaufgabe eine Verbindung zwischen Knoten im Netzwerk herzustellen. Die Netzwerkschicht soll dabei die übergeordneten Schichten von den Details der Datenübertragung über das Netzwerk befreien. Eine der wichtigsten Aufgaben der Netzwerkschicht ist z.B. die Auswahl von Paketrouten bzw. das Routing vom Absender zum Empfänger. Das Internet Protokoll (IP) ist in der Netzwerkschicht einzuordnen.

Sicherungsschicht (data link layer)

Die Aufgabe der Sicherungsschicht (Verbindungsschicht) ist die gesicherte Übertragung von Daten. Vom Sender werden hierzu die Daten in Rahmen (frames) aufgeteilt und sequentiell an den Empfänger gesendet. Vom Empfänger werden die empfangenen Daten durch Bestätigungsrahmen quittiert. Protokollbeispiele für die Sicherungsschicht sind HDLC (high-level data link control), SLIP (serial line IP) und PPP (point-to-point Protokoll).

Bitübertragungsschicht (physical layer)

Die Bitübertragungsschicht regelt die Übertragung von Bits über das Übertragungsmedium. Dies betrifft die Übertragungsgeschwindigkeit, die Bit-Codierung, den Anschluß (wieviele Pins hat der Netzanschluß?) etc. Die Festlegungen auf der Bitübertragungsschicht betreffen im wesentlichen die Eigenschaften des Übertragungsmedium.

Das TCP/IP-Referenzmodell

Im vorhergehenden Abschnitt wurde das OSI-Referenzmodell vorgestellt. In diesem Abschnitt soll nun das Referenzmodell für die TCP/IP-Architektur vorgestellt werden. Das TCP/IP-Referenzmodell - benannt nach den beiden primären Protokollen TCP und IP der Netzarchitektur beruht auf den Vorschlägen, die bei der Fortentwicklung des ARPANETs gemacht wurden. Das TCP/IP-Modell ist zeitlich vor dem OSI-Referenzmodell entstanden, deshalb sind auch die Erfahrungen des TCP/IP-Modells mit in die OSI- Standardisierung eingeflossen. Das TCP/IP-Referenzmodell besteht im Gegensatz zum OSI-Modell aus nur vier Schichten: Application Layer, Transport Layer, Internet Layer, Network Layer. Als Ziele der Architektur wurden bei der Entwicklung definiert:

• Unabhängigkeit von der verwendeten Netzwerk-Technologie

• Unabhängigkeit von der Architektur der Hostrechner

• Universelle Verbindungsmöglichkeiten im gesamten Netzwerk

• Ende-zu-Ende-Quittungen

• Standardisierte Anwendungsprotokolle.

Vergleich des OSI-Referenzmodells mit dem TCP/IP- Referenzmodell

Aufgaben der Schichten TCP/IP

Applikationsschicht (application layer)

Die Applikationsschicht (auch Verarbeitungsschicht genannt) umfaßt alle höherschichtigen Protokolle des TCP/IP-Modells. Zu den ersten Protokollen der Verarbeitungsschicht zählen TELNET (für virtuelle Terminals), FTP (Dateitransfer) und SMTP (zur Übertragung von E- Mail). Im Laufe der Zeit kamen zu den etablierten Protokollen viele weitere Protokolle wie z.B. DNS (Domain Name Service) und HTTP (Hypertext Transfer Protocol) hinzu.

Transportschicht (transport layer)

Wie im OSI-Modell ermöglicht die Transportschicht die Kommunikation zwischen den Quell- und Zielhosts. Im TCP/IP-Referenzmodell wurden auf dieser Schicht zwei Ende-zu-Ende-Protokolle definiert: das Transmission Control Protocol (TCP) und das User Datagram Protocol (UDP). TCP ist ein zuverlässiges verbindungsorientiertes Protokoll, durch das ein Bytestrom fehlerfrei einen anderen Rechner im Internet übermittelt werden kann. UDP ist ein unzuverlässiges verbindungsloses Protokoll, das vorwiegend für Abfragen und Anwendungen in Client/Server-Umgebungen verwendet wird, in denen es in erster Linie nicht um eine sehr genaue, sondern schnelle Datenübermittlung geht (z.B. Übertragung von Sprache und Bildsignalen).

Internetschicht (internet layer)

Die Internetschicht im TCP/IP-Modell definiert nur ein Protokoll namens IP (Internet Protocol), das alle am Netzwerk beteiligten Rechner verstehen können. Die Internetschicht hat die Aufgabe IP-Pakete richtig zuzustellen. Dabei spielt das Routing der Pakete eine wichtige Rolle. Das Internet Control Message Protocol (ICMP) ist fester Bestandteil jeder IP-Implementierung und dient zur Übertragung von Diagnose- und Fehlerinformationen für das Internet Protocol.

Netzwerkschicht (network layer)

Unterhalb der Internetschicht befindet sich im TCP/IP-Modell eine große Definitionslücke. Das Referenzmodell sagt auf dieser Ebene nicht viel darüber aus, was hier passieren soll. Festgelegt ist lediglich, daß zur Übermittlung von IP-Paketen ein Host über ein bestimmtes Protokoll an ein Netz angeschlossen werden muß. Dieses Protokoll ist im TCP/IP-Modell nicht weiter definiert und weicht von Netz zu Netz und Host zu Host ab. Das TCP/IP-Modell macht an dieser Stelle vielmehr Gebrauch von bereits vorhandenen Protokollen, wie z.B. Ethernet (IEEE 802.3), Serial Line IP (SLIP), etc.

Die TCP/IP-Protokoll-Architektur

Die TCP/IP-Architektur wird, wie im Abschnitt Referenzmodelle - Das TCP/IP- Referenzmodell gesagt, im allgemeinen als vierschichtiges Modell beschrieben. Oft wird das TCP/IP-Referenzmodell auch als fünfschichtiges Modell dargestellt. Andrew S. Tanenbaum bezeichnet das fünfschichtige Modell als hybrides Referenzmodell. Er schreibt dazu: "(...) Viertens unterscheidet das TCP/IP-Modell nicht zwischen den Bitübertragungs- und Sicherungsschichten (erwähnt sie nicht einmal). Diese Schichten sind völlig unterschiedlich. Die Bitübertragungsschicht hat mit den Übertragungsmerkmalen von Kupferdarht, Glasfaser und drahtlosen Kommunikationsmedien zu tun. Die Sicherungsschicht ist darauf beschränkt, den Anfang und das Ende von Rahmen abzugrenzen und sie mit der gewünschten Zuverlässigkeit von einem Ende zum anderen zu befördern. Ein korrektes Modell sollte beides als separate Schichten beinhalten. Das TCP/IP-Modell tut das nicht."

OSI-Referenzmodell TCP/IP-Referenzmodell Hybrides Referenzmodell

Einkapselung

Die Schichtung beruht auf dem Prinzip, daß eine Schicht die angebotenen Dienste der darunter liegenden Schicht in Anspruch nehmen kann. Dabei braucht die Schicht, die die Dienstleistung in Anspruch nimmt keinerlei Kenntnisse darüber haben, wie die geforderten Dienste erbracht werden. Auf diese Art und Weise wird eine Aufgabenteilung der Schichten erreicht . Daten, die von einem Applikationsprogramm über ein Netzwerk versendet werden, durchlaufen den TCP/IP-Protokollstapel von der Applikationsschicht zur Netzwerkschicht. Von jeder Schicht werden dabei Kontrollinformationen in Form eines Protokollkopfes angefügt. Diese Kontrollinformationen dienen der korrekten Zustellung der Daten. Das Zufügen von Kontrollinformationen wird als Einkapselung (encapsulation) bezeichnet.

Innerhalb der Schichten des TCP/IP-Modells werden Daten mit verschiedenen Termini benannt, da jede Schicht auch ihre eigenen Datenstrukturen hat. Applikationen, die das Transmission Control Protocol benutzen, bezeichnen Daten als Strom (stream); Applikationen, die das User Datagram Protocol verwenden, bezeichnen Daten als Nachricht (message). Auf der Transportebene bezeichnen die Protokolle TCP und UDP ihre Daten als Segment (segment) bzw. Paket (packet). Auf der Internet Schicht werden Daten allgemein als Datengramm (datagram) benannt. Oft werden die Daten hier aber auch als Paket bezeichnet. Auf der Netzwerkebene bezeichnen die meisten Netzwerke ihre Daten als Pakete oder Rahmen (frames).

Netzwerkschicht

Die Netzwerkschicht ist die unterste Schicht des TCP/IP-Modells. Protokolle, die auf dieser Schicht angesiedelt sind, legen fest, wie ein Host an ein bestimmtes Netzwerk angeschlossen wird und wie IP-Pakete über dieses Netzwerk übertragen werden. Im Gegensatz zu den Protokollen der höheren Schichten des TCP/IP- Modells, müssen die Protokolle der Netzwerkschicht sich auf die Details des verwendeten Netzwerks - wie z.B. Paketgrößen, Netzwerkadressierung, Anschlußcharakteristiken etc. - beziehen. Die Netzwerkschicht des TCP/IP-Modells umfaßt also die Aufgaben der Bitübertragungsschicht, Sicherungsschicht und Vermittlungsschicht im OSI- Modell. Die Protokolle der Netzwerkschicht sind allerdings nicht im TCP/IP-Modell definiert. Wie schon gesagt, legt das Modell lediglich fest, daß zur Übermittlung von IP-Paketen ein Host über ein bestimmtes Protokoll an ein Netzwerk angeschlossen werden muß. Die Protokolle sind im Modell nicht weiter definiert. Es werden hier vielmehr bestehende Standards verwendet und in das Modell aufgenommen. Insbesondere bedeutet dies auch, daß mit neuer Hardware-Technologie auch neue Protokolle auf der Netzwerkschicht entwickelt werden müssen, so daß TCP/IP-Netzwerke diese Hardware verwenden können. Dies ist jedoch kein Nachteil, sondern eher ein Vorteil. Durch die weitgehende Unabhängigkeit vom Übertragungsmedium können neue Netzwerktechnologien schnell in das TCP/IP-Modell aufgenommen werden. Als Beispiel soll hier Ethernet dienen.

Ethernet

1. Ethernet ist nicht von Novell sondern von Xerox in die Welt gesetzt worden.

2. Es sind da 4 Arten Ethernetframes.

CSMA/CD ist der gemeinsame Nenner. Es gibt 4 verschiedene Frametypen, welche von den Herstellern verschieden genannt werden. Verschieden, nicht unterschiedlich!

IEEE	Novel	Cisco
802.3	802.2	LLC
V II	EthernetII	ARPA
802.3 SNAP	SNAP	SNAP
802.3 Raw	802.3	Novell

CSMA/CD Carrier Sense Multiple Access/Collision Detect

Alle Stationen können gleichberechtigt auf das übertragungsmedium zugreifen.(Multiple Access) Bevor eine Station sendet, lauscht sie an der Leitung, um zu überprüfen, ob nicht schon eine andere Station sendet (Carrier Sense). Ist die Leitung frei wird gesendet. Jedoch erst nach 9,6 μs (Inter Frame Grab). Auch während des Sendens wird mitgehört (Listen While Talking). Da die Signale sich nicht unendlich schnell ausbreiten, kann es vorkommen, daß eine zweite Station trotz Carrier Sense anfängt zu senden. Beide Signale werden sich treffen. Der Signalpegel wird zwichen dem doppelten Wert und Null Schwanken. Diesen Kollisionspegel erkennen die sendenden Stationen (Collision Detect) und schicken ein JAM-Singal auf die Leitung. Das JAM-Signal besteht aus einer 32 Bit langen Folge von 1 und 0. Nach dem JAM-Singal warten die sendewilligen Stationen eine (von Algorithmen) bestimmte Zeit und beginnen erneut mit Carrier Sense. Die Wahrscheinlichkeit von Kollisionen steigt mit der Anzahl der Stationen und der Leitungslänge.

Ethernet II

Die klassische Framestruktur ist Ethernet II. Merkmal von Ethernet II ist das zwei Bytes große Typfeld. Es unterscheidet die verschiedenen Schicht 3 Protokolle. Andere Ethernet Typen haben an dieser Stelle eine Längeninformation. Wenn der Wert der beiden Bytes nach der Source-Adresse größer als die max. möglichen 1518 Bytes ist, muß es sich um Ethernet 2 handeln. Die Präambel dient zur Synchronisation der Empfänger. Sie besteht aus einer Schwingung von 6,4 μs Länge (Folge von 1010... 8 Bytes). Das Frame muß mindestens 64 Byte groß sein, um die minimale Slot-Time zur Erkennung einer Kollision zu erreichen. Anderfalls werden Bits ergänzt

Ethernet 802.3 raw

Novells 802.3 raw Novell eigener eigener Rahmentyp für IPX. Er enthält keine Protokollkennung. Er soll und kann deshalb allein IPX transportieren. Der einzige Möglichkeit einen 802.3 raw Rahmen zu erkennen besteht darin, daß nach der Rahmenlänge zwei Bytes folgen, die nur aus Einsen bestehen (0xFFFF). Der Send Frame Delimiter (SFD) hat im letzten Bit eine 1, die Marke des Ramenbegins.

IEEE 802.3

IEEE 802.3 Frames haben statt des Typenfeldes ein 2 Byte langes Längenfeld. eingefügt. Es gibt die Anzahl der Bytes im Datenfeld einschließlich 802.2 LLC-Header an. Statt Typfeld mit der Protokoll-ID ist der Destination Service Access Point (DSAP) und der Source Service Access Point (SSAP) vorhanden. Das Control Field enthält den Typ des LLC-Frames.

IEEE 802.3 SNAP

Ein Unterschied der IEEE 802.3 Definition gegenüber Ethernet II ist die Halbierung des Typ-Codes auf ein Byte, es können höchstens 256 Protokolle unterschieden werden. Ein SNAP Feld wird eingebaut. Das SNAP Feld ist 5 Byte groß, die ersten 3 Bytes enthalten den Organizationally Unique Identifier des Herstellers, die 2 weitern das Protocol Type Field, die Protokollnummer (IP=0x800). Ein Frame mit 802.2 SNAP Header hat als DSAP und SSAP immer 0xAA, im Control Field immer 0x03.

Internet-Schicht

Das Internet ist eine Sammlung von Teilnetzen, die miteinander verbunden sind. Es gibt keine echte Struktur des Netzes, sondern mehrere größere Backbones, die quasi das Rückgrat (wie der Name Backbone ja schon sagt) des Internet bilden. Die Backbones werden aus Leitungen mit sehr hoher Bandbreite und schnellen Routern gebildet. An die Backbones sind wiederum größere regionale Netze angeschlossen, die LANs von Universitäten, Behörden, Unternehmen und Service-Providern verbinden.

Internet Protokoll

Das Internet Protokoll (Internet Protocol - IP) ist der Leim, der dies alles zusammenhält. IP stellt die Basisdienste für die Übermittlung von Daten in TCP/IP-Netzen bereit und ist im RFC 791 spezifiziert. Hauptaufgaben des Internet Protokolls sind die Adressierung von Hosts und das Fragmentieren von Paketen. Diese Pakete werden von IP nach bestem Bemühen ("best effort") von der Quelle zum Ziel befördert, unabhängig davon, ob sich die Hosts im gleichen Netz befinden oder andere Netze dazwischen liegen. Garantiert ist die Zustellung allerdings nicht. Das Internet Protokoll enthält keine Funktionen für die Ende-zu-Ende-Sicherung oder für die Flußkontrolle.

Die Funktionen von IP umfassen:

Die Definition von Datengrammen zur Übermittlung von Daten im Internet bilden. Definition des Adressierungsschemas. Übermittlung der Daten von der Transportebene zur Netzwerkschicht. Routing von Datengrammen durch das Netz. Fragmentierung und Zusammensetzen von Datengrammen. IP ist ein verbindungsloses Protokoll, d.h. zur Datenübertragung wird keine Ende-zu-Ende-Verbindung der Kommunikationspartner etabliert. Ferner ist IP ein unzuverlässiges Protokoll, da es über keine Mechanismen zur Fehlererkennung und -behebung verfügt. Unzuverlässig bedeutet aber keinesfalls, daß man sich auf das IP Protokoll nicht verlassen kann. Unzuverlässig bedeutet in diesem Zusammenhang lediglich, daß IP die Zustellung der Daten nicht garantieren kann. Sind die Daten aber beim Zielhost angelangt, sind diese Daten auch korrekt.

IP-Datengramm

Die TCP/IP-Protokolle wurden entwickelt, um Daten über ein paketvermittelndes Netz (wie dem ARPANET) zu übertragen. Ein Paket ist ein Datenblock zusammen mit den Informationen, die notwendig sind, um sie dem Empfänger zuzustellen (ein Paket ist also nichts anderes als ein Paket im herkömmliche Sinn bei der Post - das Paket enthält die Daten, auf dem Paket ist die Adresse des Empfängers notiert). Das Datengramm (datagram) ist das Paketformat, das vom Internet Protokoll definiert ist. Ein IP-Datengramm besteht aus einem Header und den zu übertragenden Daten. Der Header hat einen festen 20 Byte großen Teil, gefolgt von einem optionalen Teil variabler Länge. Der Header umfaßt alle Informationen, die notwendig sind, um das Datengramm dem Empfänger zuzustellen. Ein Datengramm kann theoretisch maximal 64 KByte groß sein, in der Praxis liegt die Größe ungefähr bei 1500 Byte (das hängt mit der maximalen Rahmengröße des Ethernet-Protokolls zusammen).

Der IP-Header

Die Felder des in der Abbildung dargestellten Protokollkopfes haben die folgende Bedeutung:

Version

Das Versions-Feld enthält die Versionsnummer des IP-Protokolls. Durch die Einbindung der Versionsnummer besteht die Möglichkeit über eine längere Zeit mit verschiedenen Versionen des IP Protokolls zu arbeiten. Einige Hosts können mit der alten und andere mit der neuen Version arbeiten. Die derzeitige Versionsnummer ist 4, aber die Version 6 des IP Protokolls befindet sich bereits in der Erprobung

Length

Das Feld Length (Internet Header Length - IHL) enthält die Länge des Protokollkopfs, da diese nicht konstant ist. Die Länge wird in 32-Bit- Worten angegeben. Der kleinste zulässige Wert ist 5 - das entspricht also 20 Byte; in diesem Fall sind im Header keine Optionen gesetzt. Die Länge des Headers kann sich durch Anfügen von Optionen aber bis auf 60 Byte erhöhen (der Maximalwert für das 4-Bit-Feld ist 15).

Type of Service

Über das Feld Type of Service kann IP angewiesen werden Nachrichten nach bestimmten Kriterien zu behandeln. Als Dienste sind hier verschiedene Kombinationen aus Zuverlässigkeit und Geschwindigkeit möglich. In der Praxis wird dieses Feld aber ignoriert, hat also den Wert 0. Das Feld selbst hat den folgenden Aufbau:

Precedence

(Bits 0-2) gibt die Priorität von 0 (normal) bis 7 (Steuerungspaket) an. Die drei Flags (D,T,R) ermöglichen es dem Host anzugeben, worauf er bei der Datenübertragung am meisten Wert legt: Verzögerung (Delay - D), Durchsatz (Throughput - T), Zuverlässigkeit (Reliability - R). Die beiden anderen Bit-Felder sind reserviert.

Total Length

Enthält die gesamte Paketlänge, d.h. Header und Daten. Da es sich hierbei um ein 16-Bit-Feld handelt ist die Maximallänge eines Datengramms auf 65.535 Byte begrenzt. In der Spezifikation von IP (RFC 791) ist festgelegt, daß jeder Host in der Lage sein muß, Pakete bis zu einer Länge von 576 Bytes zu verarbeiten. In der Regel können von den Host aber Pakete größerer Länge verarbeitet werden.

Identification

Über das Identifikationsfeld kann der Zielhost feststellen, zu welchem Datengramm ein neu angekommenes Fragment gehört. Alle Fragmente eines Datengramms enthalten die gleiche Identifikationsnummer, die vom Absender vergeben wird.

Flags

Das Flags-Feld ist drei Bit lang. Die Flags bestehen aus zwei Bits namens DF - Don't Fragment und MF - More Fragments. Das erste Bit des Flags-Feldes ist ungenutzt bzw. reserviert. Die beiden Bits DF und MF steuern die Behandlung eines Pakets im Falle einer Fragmentierung. Mit dem DF-Bit wird signalisiert, daß das Datengramm nicht fragmentiert werden darf. Auch dann nicht, wenn das Paket dann evtl. nicht mehr weiter transportiert werden kann und verworfen werden muß. Alle Hosts müssen, wie schon gesagt Fragemente bzw. Datengramme mit einer Größe von 576 Bytes oder weniger verarbeiten können. Mit dem MF-Bit wird angezeigt, ob einem IP-Paket weitere Teilpakete nachfolgen. Diese Bit ist bei allen Fragmenten außer dem letzten gesetzt.

Fragment Offset

Der Fragmentabstand bezeichnet, an welcher Stelle relativ zum Beginn des gesamten Datengramms ein Fragment gehört. Mit Hilfe dieser Angabe kann der Zielhost das Originalpaket wieder aus den Fragmenten zusammensetzen. Da dieses Feld nur 13 Bit groß ist, können maximal 8192 Fragmente pro Datengramm erstellt werden. Alle Fragmente, außer dem letzten, müssen ein Vielfaches von 8 Byte sein. Dies ist die elementare Fragmenteinheit.

Time to Live

Das Feld Time to Live ist ein Zähler, mit dem die Lebensdauer von IP- Paketen begrenzt wird. Im RFC 791 ist für dieses Feld als Einheit Sekunden spezifiziert. Zulässig ist eine maximale Lebensdauer von 255 Sekunden (8 Bit). Der Zähler muß von jedem Netzknoten, der durchlaufen wird um mindestens 1 verringert werden. Bei einer längeren Zwischenspeicherung in einem Router muß der Inhalt sogar mehrmals verringert werden. Enthält das Feld den Wert 0, muß das Paket verworfen werden: damit wird verhindert, daß ein Paket endlos in einem Netz umherwandert. Der Absender wird in einem solchen Fall durch eine Warnmeldung in Form einer ICMP-Nachricht (siehe weiter unten) informiert.

Protocol

Enthält die Nummer des Transportprotokolls, an das das Paket weitergeleitet werden muß. Die Numerierung von Protokollen ist im gesamten Internet einheitlich.. Bei UNIX-Systemen sind die Protokollnummern in der Datei /etc/protocols abgelegt.

Header Checksum

Dieses Feld enthält die Prüfsumme der Felder im IP-Header. Die Nutzdaten des IP-Datengramms werden aus Effiziengründen nicht mit geprüft. Diese Prüfung findet beim Empfänger innerhalb des Transportprotokolls statt. Die Prüfsumme muß von jedem Netzknoten, der durchlaufen wird, neu berechnet werden, da der IP-Header durch das Feld Time-to-Live sich bei jeder Teilstrecke verändert. Aus diesem Grund ist auch eine sehr effiziente Bildung der Prüfsumme wichtig. Als Prüfsumme wird das 1er-Komplement der Summe aller 16-Bit- Halbwörter der zu überprüfenden Daten verwendet. Zum Zweck dieses Algorithmus wird angenommen, daß die Prüfsumme zu Beginn der Berechnung Null ist.

Source Address, Destination Address

In diese Felder werden die 32-Bit langen Internet-Adressen zur eingetragen. Die Internet-Adressen werden im nächsten Abschnitt näher betrachtet.

Options und Padding

Das Feld Options wurde im Protokollkopf aufgenommen, um die Möglichkeit zu bieten das IP-Protokoll um weitere Informationen zu ergänzen, die im ursprünglichen Design nicht berücksichtigt wurden. Das Optionsfeld hat eine variable Länge. Jede Option beginnt mit einem Code von einem Byte, über den die Option identifiziert wird. Manchen Optionen folgt ein weiteres Optionsfeld von 1 Byte und dann ein oder mehrere Datenbytes für die Option. Das Feld Options wird über das Padding auf ein Vielfaches von 4 Byte aufgefüllt. Derzeit sind die folgenden Optionen bekannt:

End of Options List

Kennzeichnet das Ende der Optionsliste.

No Option

Kann zum Auffüllen von Bits zwischen Optionen verwendet werden.

Security

Bezeichnet, wie geheim ein Datengramm ist. In der Praxis wird diese Option jedoch fast immer ignoriert.

Loose Source-Routing, Strict Source-Routing

Diese Option enthält eine Liste von Internet-Adressen, die das Datagramm durchlaufen soll. Auf diese Weise kann dem Datenpaket vorgeschrieben werden eine bestimmte Route durch das Internet zu nehmen. Beim Source-Routing wird zwischen Strict Source and Record Route und Loose Source and Record Route unterschieden. Im ersten Fall wird verlangt, daß das Paket diese Route genau einhalten muß. Desweiteren wird die genommene Route aufgezeichnet. Die zweite Variante schreibt vor, daß die angegebenen Router nicht umgangen werden dürfen. Auf dem Weg können aber auch andere Router besucht werden.

Record Route

Die Knoten, die dieses Datengramm durchläuft, werden angewiesen ihre IP-Adresse an das Optionsfeld anzuhängen. Damit läßt sich ermitteln, welche Route ein Datengramm genommen hat. Wie anfangs schon gesagt, ist die Größe für das Optionsfeld auf 40 Byte beschränkt. Deshalb kommt es heute auch oftmals zu Problemen mit dieser Option, da weit mehr Router durchlaufen werden, als dies zu Beginn des ARPANET der Fall war.

Time Stamp

Diese Option ist mit der Option Record Route vergleichbar. Zusätzlich zur IP-Adresse wird bei dieser Option die Uhrzeit des Durchlaufs durch den Knoten vermerkt.

Adressierung auf der Internet-Schicht

Zur Adressierung eines Kommunikationspartners in Form eines Applikationsprogramms müssen beim Durchlaufen der vier TCP/IP- Schichten auch vier verschiedene Adressen angegeben werden. Eine Netzwerkadresse (z.B. eine Ethernet-Adresse) Eine Internet-Adresse Eine Transportprotokoll-Adresse Eine Portnummer Zwei dieser Adressen finden sich als Felder im IP-Header: die Internet- Adresse und die Transportprotokoll-Adresse. Protokollnummern IP verwendet Protokollnummern, um empfangene Daten an das richtige Transportprotokoll weiterzuleiten. Die Protokollnummer ist ein einzelnes Byte im IP-Header. Die Protokollnummern sind im gesamten Internet einheitlich. Bisher wurden die Protokollnummern im RFC 1700 definiert. Diese Aufgabe ist nun von der Internet Assigned Numbers Authority (IANA) [1] übernommen worden. Auf UNIX-Systemen sind die Protokollnummern in der Datei /etc/protocols abgelegt. Diese Datei ist eine einfache Tabelle, die einen Protokollnamen und die damit verbundene Protokollnummer enthält. Nachfolgend ist der Inhalt der Datei /etc/protocols einer aktuellen LINUX-Maschine abgebildet:

Empfängt IP ein Datengramm, in dessen Header als Protokollnummer 6 eingetragen ist, so werden diese Daten an das Transmission Control Protocol weitergeleitet; ist die Nummer 17, werden die Daten an das User Datagram Protocol weitergeleitet etc.

IP-Adressen

Jeder Host und Router im Internet hat eine 32-Bit lange IP-Adresse. Eine IP- Adresse ist eindeutig: kein Knoten im Internet hat die gleiche IP-Adresse wie ein anderer. Maschinen, die an mehrere Netze angeschlossen sind, haben in jedem Netz eine eigene IP-Adresse. Die Netzwerkadressen wurden bisher vom Network Information Center (NIC) [2] vergeben, um Adresskonflikte zu vermeiden. Seit einiger Zeit hat diese Aufgabe die Internet Assigned Numbers Authority (IANA) [3] bzw. ihre Vertreter in den verschiedenen Gebieten - Asia Pacific Network Information Center (APNIC), American Registry for Internet Numbers (ARIN), Réseaux IP Européens (RIPE) - übernommen. Die Adressen werden nicht einzeln zugeordnet, sondern

nach Netzklassen vergeben. Beantragt man IP-Adressen für ein Netz, so erhält man nicht für jeden Rechner eine Adresse zugeteilt, sondern einen Bereich von Adressen, der selbst zu verwalten ist.

IP-Adreßformate. Wie die obere Abbildung zeigt, sind IP-Adressen in verschiedene Klassen, mit unterschiedlich langer Netzwerk- und Hostadresse, eingeteilt. Die Netzwerkadresse definiert das Netzwerk, in dem sich ein Host befindet: alle Hosts eines Netzes haben die gleiche Netzwerkadresse. Die Hostadresse identifiziert einen bestimmten Rechner innerhalb eines Netzes. Ist ein Host an mehrere Netze angeschlossen, so hat er für jedes Netz eine eigene IP-Adresse. "Eine IP-Adresse identifiziert keinen bestimmten Computer [Host], sondern eine Verbindung zwischen einem Computer [Host] und einem Netz. Einem Computer [Host] mit mehreren Netzanschlüssen (z.B. ein Router) muß für jeden Anschluß eine IP-Adresse zugewiesen werden." ([Co98]) IP-Adressen sind 32-Bit große Zahlen, die normalerweise nicht als Binärzahl, sondern in gepunkteten Dezimalzahlen geschrieben werden. In diesem Format wird die 32-Bit große Zahl in 4 Byte getrennt, die mit Punkten voneinander getrennt sind. Die Adresse 01111111111111111111111111111111 wird so z.B. als 127.255.255.255 geschrieben. Die niedrigste IP-Adresse ist 0.0.0.0., die höchste 255.255.255.255. Wie zuvor gesagt, sind IP-Adressen in Klassen unterteilt. Der Wert des ersten Bytes gibt die Adressklasse an:

Klasse A

Das erste Byte hat einen Wert kleiner als 128, d.h. das erste Bit der Adresse ist 0. Das erste Byte ist Netzwerknummer, die letzten drei Bytes identifizieren einen Host im Netz. Es gibt demzufolge also 126 Klasse A Netze, die bis zu 16 Millionen Host in einem Netz.

Klasse B

Ein Wert von 128 bis 191 für das erste Byte (das erste Bit ist gleich 1, Bit 2 gleich 0) identifiziert eine Klasse B Adresse. Die ersten beiden Bytes identifizieren das Netzwerk, die letzen beiden Bytes einen Host. Das ergibt 16382 Klasse B Netze mit bis zu 64000 Hosts in einem Netz.

Klasse C

Klasse C Netze werden über Werte von 192 bis 223 für das erste Byte (die ersten beiden Bits sind gleich 1, Bit 3 gleich 0) identifiziert. Es gibt 2 Millionen Klasse C Netze, d.h. die ersten drei Bytes werden für die Netzwerkadresse verwendet. Ein Klasse C Netz kann bis zu 254 Host beinhalten.

Klasse D

Klasse D Adressen, sogenannte Multicast-Adressen, werden dazu verwendet ein Datengramm an mehrere Hostadressen gleichzeitig zu versenden. Das erste Byte einer Multicast-Adresse hat den Wertebereich von 224 bis 239, d.h. die ersten drei Bit sind gesetzt und Bit 4 ist gleich 0. Sendet ein Prozeß eine Nachricht an eine Adresse der Klasse D, wird die Nachricht an alle Mitglieder der adressierten Gruppe versendet. Die Übermittlung der Nachricht erfolgt, wie bei IP üblich, nach bestem Bemühen, d.h. ohne Garantie, daß die Daten auch tatsächlich alle Mitglieder einer Gruppe erreichen. Für das Multicasting wird ein spezielles Protokoll namens Internet Group Management Protocol (IGMP) verwendet. IGMP entspricht grob ICMP, mit dem Unterschied, daß es nur zwei Arten von Paketen kennt: Anfragen und Antworten. Anfragen werden dazu verwendet, zu ermitteln welche Hosts Mitglieder einer Gruppe sind. Antworten informieren darüber, zu welchen Gruppen ein Host gehört. Jedes IGMP-Paket hat ein festes Format und wird zur Übertragung in IP-Pakete eingekapselt.

EXKURS: Subnetting