2. Internet Architecture (Internetarchitektur)
2. Internetarchitektur
Dieses Kapitel enthält keine Anforderungen. Es bietet jedoch nützliche Hintergrundinformationen zur Gesamtarchitektur des Internets und von Routern.
Allgemeine Hintergrundinformationen und Diskussionen zur Internet-Architektur und der unterstützenden Protokollfamilie finden sich im DDN Protocol Handbook [ARCH:1]. Für Hintergrundinformationen siehe z. B. [ARCH:2], [ARCH:3], [ARCH:4]. Die Internet-Architektur und -Protokolle werden auch in einer wachsenden Anzahl von Lehrbüchern behandelt, z. B. [ARCH:5] und [ARCH:6].
2.1 Einleitung
Das Internetsystem besteht aus vielen miteinander verbundenen Paketvermittlungsnetzen, die die Kommunikation zwischen Host-Computern mithilfe von Internet-Protokollen unterstützen. Zu diesen Protokollen gehören das Internet Protocol (Internetprotokoll, IP), das Internet Control Message Protocol (Internet-Steuerungsnachrichtenprotokoll, ICMP), das Internet Group Management Protocol (Internet-Gruppenverwaltungsprotokoll, IGMP) sowie verschiedene Transport- und Anwendungsprotokolle, die auf diesen aufbauen. Wie in Abschnitt [1.2] erwähnt, veröffentlicht die Internet Engineering Steering Group regelmäßig ein offizielles Protokoll-Memo, das alle Internet-Protokolle auflistet.
Alle Internet-Protokolle verwenden IP als grundlegenden Datenübertragungsmechanismus. IP ist ein Datagramm- oder verbindungsloser Internetzwerkdienst, der Adressierung, Diensttyp-Spezifikation, Fragmentierung und Reassemblierung sowie Sicherheitsbestimmungen umfasst. ICMP und IGMP werden als integraler Bestandteil von IP betrachtet, sind aber architektonisch über IP geschichtet. ICMP bietet Fehlerberichterstattung, Flusskontrolle, First-Hop-Router-Umleitungen und andere Wartungs- und Steuerfunktionen. IGMP bietet einen Mechanismus, mit dem Hosts und Router IP-Multicast-Gruppen beitreten und verlassen können.
Zuverlässige Datenübertragung in der Internet-Protokollfamilie wird durch Transportschichtprotokolle wie das Transmission Control Protocol (Übertragungssteuerungsprotokoll, TCP) bereitgestellt. TCP bietet Ende-zu-Ende-Neuübertragung, Neuanordnung und Verbindungssteuerung. Der verbindungslose Dienst der Transportschicht wird durch das User Datagram Protocol (Benutzerdatagrammprotokoll, UDP) bereitgestellt.
2.2 Elemente der Architektur
2.2.1 Protokollschichtung
Um über das Internetsystem zu kommunizieren, müssen Hosts einen geschichteten Protokollsatz implementieren, der die Internet-Protokollfamilie bildet. Hosts müssen in der Regel mindestens ein Protokoll aus jeder Schicht implementieren.
Die in der Internet-Architektur verwendeten Protokollschichten sind [ARCH:7]:
Anwendungsschicht (Application Layer)
Die Anwendungsschicht ist die oberste Schicht der Internet-Protokollfamilie. Die Internet-Protokollfamilie unterteilt die Anwendungsschicht nicht weiter, obwohl einige Anwendungsschichtprotokolle eine interne Unterschichtung aufweisen. Die Anwendungsschicht der Internet-Protokollfamilie kombiniert im Wesentlichen die Funktionen der beiden obersten Schichten des OSI-Referenzmodells [ARCH:8] – der Präsentationsschicht und der Anwendungsschicht. Die Anwendungsschicht der Internet-Protokollfamilie enthält auch einige Funktionen, die im OSI-Referenzmodell der Sitzungsschicht zugeordnet werden.
Wir unterscheiden zwei Klassen von Anwendungsschichtprotokollen: Benutzerprotokolle, die Benutzern direkt Dienste bereitstellen, und Unterstützungsprotokolle, die allgemeine Systemfunktionen bereitstellen. Die gebräuchlichsten Internet-Benutzerprotokolle sind:
- Telnet (Fernzugriff)
- FTP (Dateiübertragung)
- SMTP (E-Mail-Zustellung)
Es gibt viele weitere standardisierte Benutzerprotokolle und viele private Benutzerprotokolle.
Unterstützungsprotokolle werden für Host-Namenszuordnung, Bootstrap und Verwaltung verwendet und umfassen SNMP, BOOTP, TFTP, Domain Name System (DNS, Domänennamensystem) Protokolle und verschiedene Routingprotokolle.
Anwendungsschichtprotokolle, die für Router relevant sind, werden in den Kapiteln 7, 8 und 9 dieses Memos beschrieben.
Transportschicht (Transport Layer)
Die Transportschicht bietet Ende-zu-Ende-Kommunikationsdienste. Diese Schicht entspricht ungefähr der Transportschicht des OSI-Referenzmodells, kombiniert aber auch einige der Verbindungsaufbau- und -abbaufunktionen der OSI-Sitzungsschicht.
Derzeit gibt es zwei wichtige Transportschichtprotokolle:
- Transmission Control Protocol (TCP, Übertragungssteuerungsprotokoll)
- User Datagram Protocol (UDP, Benutzerdatagrammprotokoll)
TCP ist ein zuverlässiger, verbindungsorientierter Transportdienst, der Ende-zu-Ende-Zuverlässigkeit, Neuanordnung und Flusskontrolle bietet. UDP ist ein verbindungsloser (Datagramm-) Transportdienst. Die Forschungsgemeinschaft entwickelt andere Transportprotokolle, und der Satz offizieller Internet-Transportprotokolle könnte in Zukunft erweitert werden.
Transportschichtprotokolle, die für Router relevant sind, werden in Kapitel 6 beschrieben.
Internetschicht (Internet Layer)
Alle Internet-Transportprotokolle verwenden das Internet Protocol (IP, Internetprotokoll), um Daten vom Quell-Host zum Ziel-Host zu übertragen. IP ist ein verbindungsloser oder Datagramm-Internetzwerkdienst, der keine Ende-zu-Ende-Zustellungsgarantie bietet. IP-Datagramme können beschädigt werden, dupliziert werden, in falscher Reihenfolge beim Ziel-Host ankommen oder überhaupt nicht ankommen. Schichten über IP sind dafür verantwortlich, bei Bedarf zuverlässige Zustelldienste bereitzustellen. Das IP-Protokoll umfasst Bestimmungen für Adressierung, Diensttyp-Spezifikation, Fragmentierung und Reassemblierung sowie Sicherheit.
Die Datagramm- oder Verbindungslosigkeit von IP ist eine grundlegende und charakteristische Eigenschaft der Internet-Architektur.
Das Internet Control Message Protocol (ICMP, Internet-Steuerungsnachrichtenprotokoll) ist ein Steuerungsprotokoll, das als integraler Bestandteil von IP betrachtet wird, aber architektonisch über IP geschichtet ist – es verwendet IP, um Daten Ende-zu-Ende zu übertragen. ICMP bietet Fehlerberichterstattung, Überlastungsberichterstattung und First-Hop-Router-Umleitungen.
Das Internet Group Management Protocol (IGMP, Internet-Gruppenverwaltungsprotokoll) ist ein Netzwerkschichtprotokoll, das zur Einrichtung dynamischer Host-Gruppen für IP-Multicast verwendet wird.
Die Netzwerkschichtprotokolle IP, ICMP und IGMP werden in Kapitel 4 beschrieben.
Verbindungsschicht (Link Layer)
Um über direkt verbundene Netzwerke zu kommunizieren, müssen Hosts das Kommunikationsprotokoll implementieren, das für die Schnittstelle mit diesem Netzwerk verwendet wird. Dies wird als Verbindungsschichtprotokoll bezeichnet.
Einige ältere Internet-Dokumente nennen diese Schicht die Netzwerkschicht (Network Layer), was sich von der Netzwerkschicht des OSI-Referenzmodells unterscheidet.
Diese Schicht umfasst alles unterhalb der Netzwerkschicht und oberhalb der physischen Schicht (die physische Schicht ist die Medienverbindung, die Nachrichten kodiert und überträgt, normalerweise elektrisch oder optisch). Ihre Aufgabe ist die korrekte Zustellung von Nachrichten, ohne diese zu unterscheiden.
Protokolle dieser Schicht liegen normalerweise außerhalb des Bereichs der Internet-Standardisierung. Das Internet verwendet (absichtlich) so weit wie möglich bestehende Standards. Daher befassen sich Internet-Verbindungsschichtstandards normalerweise nur mit Adressauflösung und Regeln für die Übertragung von IP-Paketen über bestimmte Verbindungsschichtprotokolle. Internet-Verbindungsschichtstandards werden in Kapitel 3 beschrieben.
2.2.2 Netzwerke
Die Komponentennetzwerke eines Internetsystems müssen lediglich Paketvermittlung (verbindungslos) bereitstellen. Gemäß der IP-Dienstspezifikation können Datagramme in falscher Reihenfolge zugestellt werden, verloren gehen, dupliziert werden und/oder Fehler enthalten.
Damit Protokolle, die IP verwenden (z. B. TCP), eine angemessene Leistung erzielen, muss die Verlustrate des Netzwerks sehr gering sein. In Netzwerken, die verbindungsorientierte Dienste bereitstellen, verbessert die durch virtuelle Schaltkreise bereitgestellte zusätzliche Zuverlässigkeit die Ende-zu-Ende-Robustheit des Systems, ist aber für den Internet-Betrieb nicht erforderlich.
Komponentennetzwerke lassen sich in der Regel in zwei Kategorien einteilen:
Lokale Netzwerke (Local-Area Networks, LANs)
LANs können verschiedene Designs aufweisen. LANs decken in der Regel ein kleines geografisches Gebiet ab (z. B. ein einzelnes Gebäude oder Fabrikgelände) und bieten geringe Latenz bei hoher Bandbreite. LANs können passiv (wie Ethernet) oder aktiv (wie ATM) sein.
Weitverkehrsnetze (Wide-Area Networks, WANs)
Geografisch verteilte Hosts und LANs sind über Weitverkehrsnetze (auch als Langstreckennetzwerke bezeichnet) miteinander verbunden. Diese Netzwerke können eine komplexe interne Leitungs- und Paketvermittlungsstruktur aufweisen oder so einfach wie eine Punkt-zu-Punkt-Leitung sein.
2.2.3 Router
Im Internet-Modell sind Komponentennetzwerke über IP-Datagramm-Weiterleitungsgeräte verbunden, die als Router oder IP-Router bezeichnet werden. In diesem Dokument ist die Verwendung des Begriffs „Router" gleichbedeutend mit IP-Router. Viele ältere Internet-Dokumente bezeichnen Router als Gateways (gateways).
Historisch gesehen wurden Router durch Paketvermittlungssoftware implementiert, die auf Allzweck-CPUs lief. Da die Entwicklung von kundenspezifischer Hardware jedoch günstiger geworden ist und ein höherer Durchsatz erforderlich ist, wird dedizierte Hardware immer häufiger eingesetzt. Diese Spezifikation gilt für Router unabhängig von der Implementierungsmethode.
Router sind mit zwei oder mehr logischen Schnittstellen verbunden, die durch IP-Subnetze oder nummerlose Punkt-zu-Punkt-Leitungen dargestellt werden (beschrieben in Abschnitt [2.2.7]). Daher haben sie mindestens eine physische Schnittstelle. Die Weiterleitung von IP-Datagrammen erfordert in der Regel, dass der Router die Adresse des nächsten Hop-Routers und die zugehörige Schnittstelle oder (beim letzten Hop) den Ziel-Host auswählt. Diese Auswahl wird als Relaying (Weiterleitung) oder Forwarding (Weitervermittlung) bezeichnet und hängt von einer Routing-Datenbank im Router ab. Die Routing-Datenbank wird auch als Routing-Tabelle (routing table) oder Weiterleitungstabelle (forwarding table) bezeichnet. Der Begriff „Router" leitet sich von dem Prozess ab, diese Routing-Datenbank aufzubauen. Routingprotokolle und Konfiguration interagieren in einem Prozess namens Routing (Routing).
Die Routing-Datenbank muss dynamisch gepflegt werden, um die aktuelle Topologie des Internetsystems widerzuspiegeln. Router erreichen dies in der Regel durch die Teilnahme an verteilten Routing- und Erreichbarkeitsalgorithmen zusammen mit anderen Routern im selben autonomen System.
Router bieten nur Datagrammübertragung und versuchen, die für die Aufrechterhaltung dieses Dienstes erforderlichen Zustandsinformationen zu minimieren, um Routing-Flexibilität und -Robustheit zu erzielen.
Paketvermittlungsgeräte können auch auf der Verbindungsschicht arbeiten. Solche Geräte werden üblicherweise als Bridges (Brücken) bezeichnet. Netzwerksegmente, die durch Bridges verbunden sind, teilen dasselbe IP-Netzwerkpräfix und bilden ein einzelnes IP-Subnetz. Diese anderen Geräte liegen außerhalb des Geltungsbereichs dieses Dokuments.
2.2.4 Autonome Systeme
Ein Autonomous System (AS, autonomes System) ist ein verbundenes Segment der Netzwerktopologie, das aus einer Reihe von Subnetzwerken (an die Hosts angeschlossen sind) besteht, die durch eine Reihe von Routern miteinander verbunden sind. Die Subnetzwerke und Router werden voraussichtlich unter der Kontrolle einer einzigen Betriebs- und Wartungsorganisation (O&M) stehen. Innerhalb eines AS können Router ein oder mehrere interne Routingprotokolle und manchmal mehrere Metriksätze verwenden. Von einem AS wird erwartet, dass es anderen ASen gegenüber ein konsistentes Bild eines internen Routingplans und ein konsistentes Bild der über das AS erreichbaren Ziele präsentiert. Ein AS wird durch eine autonome Systemnummer identifiziert.
Das AS-Konzept spielt eine wichtige Rolle beim Internet-Routing (siehe Abschnitt 7.1).
2.2.5 Adressierungsarchitektur
IP-Datagramme tragen eine 32-Bit-Quell- und Zieladresse, wobei jede Adresse in zwei Teile aufgeteilt ist – ein Komponentennetzwerkpräfix und eine Host-Nummer in diesem Netzwerk. Die Notation:
IP-address ::= { <Network-prefix>, <Host-number> }
Um ein Datagramm letztendlich zuzustellen, muss der letzte Router im Pfad den Host-Nummer-Teil (oder den verbleibenden Teil) der IP-Adresse auf die Verbindungsschichtadresse des Hosts abbilden.
2.2.5.1 Klassische IP-Adressierungsarchitektur (Classical IP Addressing Architecture)
Obwohl anderswo ausreichend dokumentiert [INTERNET:2], ist es nützlich, die historische Verwendung von Netzwerkpräfixen zu erläutern. Die zur Beschreibung verwendete Sprache wird in diesem und anderen Dokumenten verwendet und durchdringt das Denken hinter vielen Protokollen.
Das einfachste klassische Netzwerkpräfix ist ein Klasse-A-, B-, C-, D- oder E-Netzwerkpräfix. Diese Adressbereiche werden durch Beobachtung der Werte der höchstwertigen Bits der Adresse und Zerlegung der Adresse in einfache Präfix- und Host-Nummernfelder unterschieden. Dies wird in [INTERNET:18] beschrieben. Kurz gesagt ist die Klassifizierung wie folgt:
0xxx - Klasse A - Allgemeine Unicast-Adressen mit standardmäßigem 8-Bit-Präfix
10xx - Klasse B - Allgemeine Unicast-Adressen mit standardmäßigem 16-Bit-Präfix
110x - Klasse C - Allgemeine Unicast-Adressen mit standardmäßigem 24-Bit-Präfix
1110 - Klasse D - IP-Multicast-Adressen - 28-Bit-Präfix, nicht aggregierbar
1111 - Klasse E - Reserviert für experimentelle Nutzung
Dieses einfache Konzept wurde durch das Konzept der Subnetze (subnets) erweitert. Subnetze wurden eingeführt, um das Internetsystem vor einer explosionsartigen Zunahme der Komplexität bei der Zuweisung von Netzwerkpräfixen und beim Routing zu schützen, während gleichzeitig die interne Verbindungsstruktur von LANs innerhalb einer Organisation beliebig komplex sein kann. Subnetze bieten dem Internetsystem eine mehrstufige hierarchische Routingstruktur. Die Subnetzerweiterung wird in [INTERNET:2] beschrieben und ist ein wesentlicher Bestandteil der Internet-Architektur. Die Grundidee besteht darin, das <Host-number>-Feld in zwei Teile aufzuteilen: eine Subnetz-Nummer und die eigentliche Host-Nummer in diesem Subnetz:
IP-address ::=
{ <Network-number>, <Subnet-number>, <Host-number> }
Die miteinander verbundenen physischen Netzwerke innerhalb einer Organisation verwenden dasselbe Netzwerkpräfix, aber unterschiedliche Subnetz-Nummern. Die Unterscheidung zwischen Subnetzen eines solchen subnetzbasierten Netzwerks ist normalerweise außerhalb dieses Netzwerks nicht sichtbar. Daher verwendet das Routing im Rest des Internets nur den <Network-prefix>-Teil der IP-Zieladresse. Router außerhalb des Netzwerks behandeln <Network-prefix> und <Host-number> zusammen als den uninterpretierten Rest der 32-Bit-IP-Adresse. Innerhalb eines subnetzbasierten Netzwerks verwenden Router das erweiterte Netzwerkpräfix:
{ <Network-number>, <Subnet-number> }
Die Bitpositionen, die diese erweiterte Netzwerknummer enthalten, wurden historisch durch eine 32-Bit-Maske angezeigt, die als Subnetzmaske bezeichnet wird. Die <Subnet-number>-Bits SOLLTEN zusammenhängend sein und zwischen dem <Network-number>-Feld und dem <Host-number>-Feld liegen. Neuere Protokolle verweisen nicht auf Subnetzmasken, sondern auf Präfixlängen. Der „Präfix"-Teil einer Adresse ist der Teil, der durch die Subnetzmaske ausgewählt wird, wobei die höchstwertigen Bits dieser Maske alle 1 und der Rest 0 sind. Die Länge des Präfixes entspricht der Anzahl der Einsen in der Subnetzmaske. Dieses Dokument geht davon aus, dass alle Subnetzmasken als Präfixlängen ausgedrückt werden können.
Die Erfinder des Subnetz-Mechanismus gingen davon aus, dass es für jeden Teil eines Organisationsnetzwerks nur eine Subnetz-Nummer gibt. In der Praxis hat sich häufig herausgestellt, dass es notwendig oder nützlich ist, mehrere Subnetze auf einem einzigen physischen Kabel zu teilen. Daher müssen Router in der Lage sein, mehrere Subnetze auf derselben physischen Schnittstelle zu konfigurieren und sie (aus Routing- oder Weiterleitungsperspektive) als verschiedene physische Schnittstellen zu behandeln.
2.2.5.2 Classless Inter Domain Routing (CIDR, Klassenloses Inter-Domain-Routing)
Das explosive Wachstum des Internets hat eine Überprüfung der Adresszuweisungsrichtlinien erzwungen. Die herkömmliche Verwendung von Allzweck-Netzwerken (Klasse A, B und C) wurde geändert, um den 32-Bit-Adressraum von IP effizienter zu nutzen. Classless Inter Domain Routing (CIDR, klassenloses Inter-Domain-Routing) [INTERNET:15] ist die Methode, die derzeit im Internet-Backbone eingesetzt wird, um diese Effizienzsteigerung zu realisieren. CIDR basiert auf der Zuweisung und dem Routing zu Netzwerken beliebiger Größe. In diesem Modell machen Hosts und Router keine Annahmen über die Adressierungsnutzung im Internet. Der Klasse-D-Adressraum (IP-Multicast) und der Klasse-E-Adressraum (experimentell) sind reserviert, aber dies ist hauptsächlich eine Zuweisungsrichtlinie.
Per Definition umfasst CIDR drei Elemente:
- Topologisch sinnvolle Adresszuweisung
- Routingprotokolle, die Netzwerkschicht-Erreichbarkeitsinformationen aggregieren können, und
- Einen konsistenten Weiterleitungsalgorithmus („Longest Match", längste Übereinstimmung)
Die Verwendung von Netzwerken und Subnetzen ist heute historisch, aber die zur Beschreibung verwendete Sprache ist noch in Gebrauch. Sie wurden durch das handlichere Konzept des Netzwerkpräfixes ersetzt. Per Definition ist ein Netzwerkpräfix eine zusammenhängende Menge von Bits am bedeutenderen Ende einer Adresse, die eine Menge von Systemen definiert. Die Host-Nummer trifft eine Auswahl innerhalb dieser Systeme. Es ist nicht erforderlich, dass das gesamte Internet Netzwerkpräfixe einheitlich verwendet. Um Routing-Informationen zu komprimieren, ist es nützlich, das Internet in Adressierungsdomänen aufzuteilen. Innerhalb einer solchen Domäne können detaillierte Informationen über Komponentennetzwerke abgerufen werden. Außerhalb der Domäne wird nur das gemeinsame Netzwerkpräfix angekündigt.
Die klassische IP-Adressierungsarchitektur verwendet Adressen und Subnetzmasken, um Host-Nummern und Netzwerkpräfixe zu unterscheiden. Bei Verwendung von Netzwerkpräfixen reicht es aus, die Anzahl der Bits im Präfix anzugeben. Beide Darstellungen sind gebräuchlich. Architektonisch korrekte Subnetzmasken können mit der Präfixlängenbeschreibung ausgedrückt werden. Sie enthalten eine Teilmenge aller möglichen Bitmuster wie folgt:
- Eine zusammenhängende Folge von Einsen am bedeutenderen Ende
- Eine zusammenhängende Folge von Nullen am weniger bedeutenden Ende, und
- Keine Bits dazwischen
Router SOLLTEN Routen immer als Netzwerkpräfixe behandeln und Konfigurations- und Routing-Informationen ablehnen SOLLTEN, die nicht mit diesem Modell übereinstimmen.
IP-address ::= { <Network-prefix>, <Host-number> }
Eine Konsequenz der Verwendung von CIDR ist, dass die mit Adresspräfixen in der Routing-Tabelle verknüpften Zielmengen Teilmengenbeziehungen aufweisen können. Eine Route, die eine kleinere Zielmenge (längeres Präfix) beschreibt, wird als spezifischer (more specific) bezeichnet als eine Route, die eine größere Zielmenge (kürzeres Präfix) beschreibt. Ebenso wird eine Route, die eine größere Zielmenge (kürzeres Präfix) beschreibt, als weniger spezifisch (less specific) bezeichnet als eine Route, die eine kleinere Zielmenge (längeres Präfix) beschreibt. Router müssen beim Weiterleiten von Datenverkehr die am spezifischsten übereinstimmende Route (das längste übereinstimmende Netzwerkpräfix) verwenden.
2.2.6 IP-Multicast (IP Multicasting)
IP-Multicast ist eine Erweiterung des Verbindungsschicht-Multicasts auf das IP-Internet. Mit IP-Multicast kann ein einzelnes Datagramm an mehrere Hosts gesendet werden, ohne es an alle Hosts zu senden. Bei entsprechender Erweiterung können sich diese Hosts in verschiedenen Adressierungsdomänen befinden. Diese Menge von Hosts wird als Multicast-Gruppe (multicast group) bezeichnet. Jede Multicast-Gruppe wird als Klasse-D-IP-Adresse dargestellt. An diese Gruppe gesendete IP-Datagramme werden jedem Gruppenmitglied mit derselben Best-Effort-Zustellmethode zugestellt, die für Unicast-IP-Datenverkehr bereitgestellt wird. Der Sender eines Datagramms muss selbst kein Mitglied der Zielgruppe sein.
Die Semantik der IP-Multicast-Gruppenmitgliedschaft ist in [INTERNET:4] definiert. Dieses Dokument beschreibt, wie Hosts und Router Multicast-Gruppen beitreten und verlassen. Es definiert auch das Protokoll zur Überwachung der IP-Multicast-Gruppenmitgliedschaft, das Internet Group Management Protocol (IGMP, Internet-Gruppenverwaltungsprotokoll).
Die Weiterleitung von IP-Multicast-Datagrammen erfolgt über statische Routing-Informationen oder Multicast-Routingprotokolle. Geräte, die IP-Multicast-Datagramme weiterleiten, werden als Multicast-Router (multicast routers) bezeichnet. Sie können IP-Unicast weiterleiten oder auch nicht. Multicast-Datagramme werden basierend auf Quell- und Zieladresse weitergeleitet. Die Weiterleitung von IP-Multicast-Paketen wird in Abschnitt [5.2.1] ausführlicher beschrieben. Anhang D beschreibt Multicast-Routingprotokolle.
2.2.7 Nummerlose Leitungen und Netzwerkpräfixe (Unnumbered Lines and Network Prefixes)
Traditionell hat jede Netzwerkschnittstelle auf einem IP-Host oder -Router eine eigene IP-Adresse. Dies kann zu einer ineffizienten Nutzung des knappen IP-Adressraums führen, da jeder Punkt-zu-Punkt-Link ein IP-Netzwerkpräfix zugewiesen werden muss.
Um dieses Problem zu lösen, haben viele das Konzept der nummerlosen Punkt-zu-Punkt-Leitungen (unnumbered point to point lines) vorgeschlagen und implementiert. Nummerlose Punkt-zu-Punkt-Leitungen haben kein zugehöriges Netzwerkpräfix. Daher haben Netzwerkschnittstellen, die mit nummerlosen Punkt-zu-Punkt-Leitungen verbunden sind, keine IP-Adresse.
Da die IP-Architektur traditionell davon ausgeht, dass alle Schnittstellen eine IP-Adresse haben, verursachen diese nummerlosen Schnittstellen einige interessante Dilemmata. Einige IP-Optionen (wie Record Route) erfordern beispielsweise, dass Router eine Schnittstellenadresse in die Option einfügen, aber nummerlose Schnittstellen haben keine IP-Adresse. Grundlegender (wie in Kapitel 5 zu sehen) enthalten Routen die IP-Adresse des nächsten Hop-Routers. Router erwarten, dass sich diese IP-Adresse in einem IP-(Sub-)Netzwerk befindet, mit dem der Router verbunden ist. Wenn die einzige Verbindung eine nummerlose Punkt-zu-Punkt-Leitung ist, wird diese Annahme natürlich verletzt.
Um diese Schwierigkeiten zu lösen, wurden zwei Schemata konzipiert. Das erste Schema besagt, dass zwei Router, die über eine nummerlose Punkt-zu-Punkt-Leitung verbunden sind, eigentlich keine zwei Router sind, sondern zwei Halb-Router, die zusammen einen einzigen virtuellen Router bilden. Die nummerlose Punkt-zu-Punkt-Leitung wird im Wesentlichen als interner Bus innerhalb des virtuellen Routers behandelt. Die beiden Hälften des virtuellen Routers müssen ihre Aktivitäten koordinieren, um genau wie ein einzelner Router zu funktionieren.
Dieses Schema passt zur IP-Architektur, hat aber zwei wichtige Nachteile. Erstens behandelt es den häufigen Fall einer einzelnen nummerlosen Punkt-zu-Punkt-Leitung, lässt sich aber nicht leicht auf den Fall eines Netzes von Routern und nummerlosen Punkt-zu-Punkt-Leitungen erweitern. Der zweite Nachteil ist, dass die Interaktion zwischen den Halb-Routern notwendigerweise komplex und nicht standardisiert ist, was die Verbindung von Geräten verschiedener Hersteller über nummerlose Punkt-zu-Punkt-Leitungsverbindungen praktisch ausschließt.
Aufgrund dieser Nachteile übernimmt dieses Memo ein alternatives Schema. Es wurde viele Male erfunden, wird aber wahrscheinlich zuerst Phil Karn zugeschrieben. In diesem Schema hat ein Router mit nummerlosen Punkt-zu-Punkt-Leitungen auch eine spezielle IP-Adresse, die in diesem Memo als Router-ID (router-id) bezeichnet wird. Die Router-ID ist eine der IP-Adressen des Routers (ein Router muss mindestens eine IP-Adresse haben). Diese Router-ID wird als IP-Adresse für alle nummerlosen Schnittstellen verwendet.
2.2.8 Besondere Sonderfälle (Notable Oddities)
2.2.8.1 Eingebettete Router (Embedded Routers)
Ein Router kann ein eigenständiges Computersystem sein, das ausschließlich für IP-Router-Funktionen vorgesehen ist. Oder Router-Funktionen können in ein Host-Betriebssystem eingebettet werden, das Verbindungen zu zwei oder mehr Netzwerken unterstützt. Das bekannteste Beispiel für ein Betriebssystem mit eingebettetem Router-Code ist das Berkeley BSD-System. Eingebettete Router-Funktionen scheinen den Aufbau von Netzwerken zu erleichtern, haben aber viele versteckte Fallstricke:
(1) Wenn ein Host nur eine konfigurierte Netzwerkschnittstelle hat, DARF er NICHT als Router fungieren.
Zum Beispiel kann ein Host mit eingebettetem Router-Code, der Broadcast-Pakete unaufgefordert weiterleitet oder Datagramme im selben Netzwerk weiterleitet, normalerweise eine Paketlawine verursachen.
(2) Wenn ein (Multi-Homed) Host als Router fungiert, unterliegt er den in diesem Dokument enthaltenen Router-Anforderungen.
Zum Beispiel sind Routingprotokoll-Probleme und Router-Steuerungs- und Überwachungsprobleme für eingebettete Router genauso schwierig und wichtig wie für eigenständige Router.
Internet-Router-Anforderungen und -Spezifikationen können sich unabhängig von Betriebssystemänderungen ändern. Verwaltungsabteilungen, die eingebettete Router im Internet betreiben, werden dringend empfohlen, den Router-Code zu pflegen und zu aktualisieren. Dies kann den Zugang zum Router-Quellcode erfordern.
(3) Wenn ein Host eingebetteten Router-Code ausführt, wird er Teil der Internet-Infrastruktur. Daher können Software- oder Konfigurationsfehler die Kommunikation zwischen anderen Hosts beeinträchtigen. Daher müssen Host-Administratoren ein gewisses Maß an Autonomie aufgeben.
In vielen Fällen müssen Host-Administratoren den in das Betriebssystem eingebetteten Router-Code deaktivieren. Daher sollte es einfach sein, eingebettete Router-Funktionen zu deaktivieren.
(4) Wenn ein Host, der eingebetteten Router-Code ausführt, auch für andere Dienste verwendet wird, können die Betriebs- und Wartungsanforderungen der beiden Nutzungsmodi in Konflikt geraten.
Zum Beispiel wird Router-O&M oft remote von einem Betriebszentrum aus durchgeführt. Dies kann privilegierten Systemzugang erfordern, den Host-Administratoren normalerweise nicht verteilen möchten.
2.2.8.2 Transparente Router (Transparent Routers)
Es gibt zwei grundlegende Modelle für die Verbindung von lokalen Netzwerken mit Weitverkehrsnetzen (oder Langstreckennetzwerken) im Internet. Im ersten Modell wird dem lokalen Netzwerk ein Netzwerkpräfix zugewiesen, und alle Router im Internet müssen wissen, wie sie zu diesem Netzwerk routen. Im zweiten Modell teilt das lokale Netzwerk (einen kleinen Teil des) Adressraums des Weitverkehrsnetzes. Router, die das zweite Modell unterstützen, werden als Adressfreigabe-Router oder transparente Router (transparent routers) bezeichnet. Der Fokus dieses Memos liegt auf Routern, die das erste Modell unterstützen, aber dies soll die Verwendung transparenter Router nicht ausschließen.
Die Grundidee transparenter Router ist, dass Hosts in lokalen Netzwerken hinter solchen Routern den Adressraum des Weitverkehrsnetzes vor dem Router teilen. In einigen Fällen ist dies ein sehr nützlicher Ansatz, und die Einschränkungen stellen keine wesentlichen Nachteile dar.
Die Wörter „vor" und „hinter" weisen auf eine der Einschränkungen dieses Ansatzes hin: Dieses Verbindungsmodell eignet sich nur für geografisch (und topologisch) begrenzte Stub-Umgebungen. Es ist erforderlich, dass eine Form der logischen Adressierung im Netzwerkebenen-Adressierungsschema des Weitverkehrsnetzes vorhanden ist. IP-Adressen in der lokalen Umgebung werden auf eine kleine Anzahl (normalerweise eine) physischer Adressen des Weitverkehrsnetzes abgebildet. Diese Abbildung erfolgt auf eine Weise, die mit der im gesamten Weitverkehrsnetz verwendeten {IP-Adresse <-> Netzwerkadresse}-Abbildung konsistent ist.
Multi-Homing in einem Weitverkehrsnetz ist möglich, kann aber zu Routing-Problemen führen, wenn die Schnittstellen geografisch oder topologisch getrennt sind. Multi-Homing in zwei (oder mehr) Weitverkehrsnetzen ist aufgrund von Adressverwirrung problematisch.
Wenn ein transparenter Router den normalen Weitverkehrsnetz-Dienst nicht vollständig emulieren kann, kann ein Host ein anderes Verhalten sehen als andere Hosts im selben Netzwerk. Zum Beispiel bietet das im ARPANET verwendete Verbindungsschichtprotokoll eine Destination Dead-Anzeige, wenn versucht wird, an einen Offline-Host zu senden. Wenn sich jedoch ein transparenter Router zwischen dem ARPANET und einem Ethernet befindet, erhalten Hosts im ARPANET keine Destination Dead-Anzeige für Ethernet-Hosts.
2.3 Router-Eigenschaften (Router Characteristics)
Internet-Router führen folgende Funktionen aus:
(1) Konformität mit bestimmten in diesem Dokument spezifizierten Internet-Protokollen: Internet Protocol (IP), Internet Control Message Protocol (ICMP) und bei Bedarf anderen Protokollen.
(2) Schnittstelle zu zwei oder mehr Paketnetzwerkschnittstellen. Für jedes verbundene Netzwerk muss der Router die für dieses Netzwerk erforderlichen Funktionen implementieren. Diese Funktionen umfassen in der Regel:
-
Kapselung und Entkapselung von IP-Datagrammen in Verbindungsschicht-Frames des verbundenen Netzwerks (z. B. Ethernet-Header und -Prüfsumme)
-
Senden und Empfangen von IP-Datagrammen mit einer maximalen Größe, die dem Maximum Transmission Unit (MTU, maximale Übertragungseinheit) des Netzwerks entspricht
-
Übersetzung von IP-Zieladressen in geeignete Netzwerkebenen-Adressen des verbundenen Netzwerks (z. B. Ethernet-Hardware-Adressen), falls erforderlich, und
-
Reaktion auf Netzwerkverkehrssteuerung und Fehleranzeigen, falls vorhanden
Siehe Kapitel 3 (Verbindungsschicht).
(3) Empfang und Weiterleitung von Internet-Datagrammen. Wichtige Aspekte dieses Prozesses sind Pufferverwaltung, Überlastungssteuerung und Fairness.
-
Identifizierung von Fehlerzuständen und Generierung von ICMP-Fehler- und Informationsnachrichten nach Bedarf.
-
Verwerfen von Datagrammen, deren Time-to-Live-Feld (Lebensdauer) null erreicht hat.
-
Fragmentierung von Datagrammen nach Bedarf, um in die MTU des nächsten Netzwerks zu passen.
Für Details siehe Kapitel 4 (Netzwerkschicht - Protokolle) und Kapitel 5 (Netzwerkschicht - Weiterleitung).
(4) Auswahl des nächsten Hop-Ziels für jedes IP-Datagramm basierend auf Informationen in der Routing-Datenbank. Für Details siehe Kapitel 5 (Netzwerkschicht - Weiterleitung).
(5) (Normalerweise) Unterstützung eines Interior Gateway Protocol (IGP, internes Gateway-Protokoll), um verteilte Routing- und Erreichbarkeitsalgorithmen mit anderen Routern im selben autonomen System auszuführen. Darüber hinaus müssen einige Router ein Exterior Gateway Protocol (EGP, externes Gateway-Protokoll) unterstützen, um Topologieinformationen mit anderen autonomen Systemen auszutauschen. Für Details siehe Kapitel 7 (Anwendungsschicht - Routingprotokolle).
(6) Bereitstellung von Netzwerkverwaltungs- und Systemunterstützungseinrichtungen, einschließlich Laden, Debuggen, Statusberichten, Ausnahmeberichten und Steuerung. Für Details siehe Kapitel 8 (Anwendungsschicht - Netzwerkverwaltungsprotokolle) und Kapitel 10 (Betrieb und Wartung).
Router-Hersteller haben viele Möglichkeiten hinsichtlich der Fähigkeiten, Komplexität und Funktionen bestimmter Router-Produkte. Es kann nützlich sein zu beobachten, dass das Internetsystem weder homogen noch vollständig verbunden ist. Aus technischen und geografischen Gründen hat es sich zu einem globalen Verbindungssystem mit LAN-Rändern entwickelt. Diese Rand-LANs sind zunehmend reich miteinander verbunden, werden dadurch weniger randständig und stellen höhere Anforderungen an Router-Anforderungen.
-
Das globale Verbindungssystem besteht aus vielen Weitverkehrsnetzen, die Router mehrerer autonomer Systeme verbinden. Relativ wenige Hosts sind direkt mit dem System verbunden.
-
Die meisten Hosts sind mit LANs verbunden. Viele Organisationen haben Cluster von LANs, die durch lokale Router miteinander verbunden sind. Jeder solche Cluster ist an einem oder mehreren Punkten über Router mit dem globalen Verbindungssystem verbunden. Wenn er nur an einem Punkt verbunden ist, wird das LAN als Stub-Netzwerk (stub network) bezeichnet.
Router im globalen Verbindungssystem benötigen in der Regel:
Erweiterte Routing- und Weiterleitungsalgorithmen (Advanced Routing and Forwarding Algorithms)
Diese Router benötigen hochdynamische Routing-Algorithmen, die minimale Verarbeitungs- und Kommunikationsbelastung auferlegen und Diensttyp-Routing bereitstellen. Überlastung ist noch kein vollständig gelöstes Problem (siehe Abschnitt [5.3.6]). Da die Forschungsgemeinschaft diese Probleme aktiv untersucht, sind Verbesserungen in diesen Bereichen zu erwarten.
Hohe Verfügbarkeit (High Availability)
Diese Router müssen hochzuverlässig sein und einen 24/7-Dienst bereitstellen. Hardware- und Softwarefehler können weitreichende (manchmal globale) Auswirkungen haben. Im Fehlerfall muss eine schnelle Wiederherstellung erfolgen. In jeder Umgebung müssen Router hochrobust sein und unter extremen Überlastungs- oder Netzwerkressourcenausfallbedingungen, möglicherweise in einem degradierten Zustand, funktionieren können.
Erweiterte O&M-Funktionen (Advanced O&M Features)
Internet-Router arbeiten normalerweise unbeaufsichtigt. Sie werden normalerweise remote von einem zentralen Überwachungszentrum aus betrieben. Sie müssen fortschrittliche Methoden zur Überwachung und Messung von Datenverkehr und anderen Ereignissen sowie zur Diagnose von Fehlern bereitstellen.
Hohe Leistung (High Performance)
Die häufigsten Langstreckenleitungen im heutigen Internet sind Vollduplex 56 KBPS, DS1 (1,544 Mbps) oder DS3 (45 Mbps). LANs sind Halbduplex-Mehrfachzugriffsmedien, normalerweise Ethernet (10 Mbps), in geringerem Maße FDDI (100 Mbps). Netzwerkmedientechnologie schreitet jedoch kontinuierlich voran und wird in Zukunft schneller sein.
Die Anforderungen an Router, die am LAN-Rand (z. B. Campus-Netzwerke) verwendet werden, hängen stark von den Bedürfnissen der lokalen Netzwerke ab. Diese können Hochleistungs- oder Mittelklassegeräte sein, die wettbewerbsfähig von mehreren verschiedenen Herstellern beschafft und von internen Organisationen (z. B. Campus-Rechenzentren) betrieben werden. Das Design dieser Router sollte niedrige durchschnittliche Latenz und gute Burst-Leistung sowie latenz- und diensttypempfindliches Ressourcenmanagement betonen. In dieser Umgebung kann O&M weniger formal sein, ist aber nicht weniger wichtig. Da Netzwerke komplexer und stärker vernetzt werden, wird die Notwendigkeit, dass Routing-Mechanismen hochdynamisch sind, wichtiger. Benutzer werden mehr von lokaler Konnektivität verlangen, um mit der Geschwindigkeit globaler Konnektivität Schritt zu halten.
Da Netzwerke wachsen und immer mehr Netzwerke alt genug werden, um alte Ausrüstung außer Betrieb zu nehmen, wird es immer dringlicher, dass Router mit Routern anderer Hersteller interoperieren.
Das Internetsystem ist nicht vollständig verbunden, aber viele Teile des Systems benötigen redundante Verbindungen. Reichhaltige Konnektivität ermöglicht zuverlässigen Dienst auch bei Kommunikationsleitungs- und Router-Ausfällen, kann den Dienst verbessern, indem Internet-Pfade verkürzt und zusätzliche Kapazität bereitgestellt wird. Leider kann diese reichhaltigere Topologie die Auswahl des optimalen Pfads zu einem bestimmten Ziel schwieriger machen.
2.4 Architektonische Annahmen (Architectural Assumptions)
Die aktuelle Internet-Architektur basiert auf einer Reihe von Annahmen über das Kommunikationssystem. Die für Router relevantesten Annahmen sind:
Das Internet ist ein Netzwerk von Netzwerken (The Internet is a network of networks)
Jeder Host ist direkt mit einem bestimmten Netzwerk verbunden. Die Verbindung zum Internet ist nur konzeptionell. Zwei Hosts im selben Netzwerk kommunizieren mit demselben Protokollsatz, den sie für die Kommunikation mit Hosts in entfernten Netzwerken verwenden.
Router speichern keine Verbindungszustandsinformationen (Routers do not keep connection state information)
Um die Robustheit des Kommunikationssystems zu verbessern, sind Router zustandslos konzipiert und leiten jedes IP-Paket unabhängig weiter. Daher können redundante Pfade genutzt werden, um trotz Zwischen-Router- und Netzwerkausfällen robusten Dienst bereitzustellen.
Alle Zustandsinformationen, die für Ende-zu-Ende-Flusskontrolle und Zuverlässigkeit erforderlich sind, werden in Hosts in der Transportschicht oder Anwendung implementiert. Daher koexistieren alle Verbindungssteuerungsinformationen mit den Endpunkten der Kommunikation und gehen nur verloren, wenn die Endpunkte ausfallen. Router steuern den Nachrichtenfluss nur indirekt, indem sie Pakete verwerfen oder die Netzwerkverzögerung erhöhen.
Beachten Sie, dass zukünftige Protokollentwicklungen wahrscheinlich dazu führen werden, dass mehr Zustand in Routern platziert wird. Dies gilt möglicherweise insbesondere für Multicast-Routing, Ressourcenreservierung und flussbasierte Weiterleitung.
Routing-Komplexität sollte in Routern liegen (Routing complexity should be in the routers)
Routing ist ein komplexes und schwieriges Problem und sollte von Routern und nicht von Hosts durchgeführt werden. Ein wichtiges Ziel ist es, Host-Software von Änderungen zu befreien, die durch die unvermeidliche Evolution der Internet-Routing-Architektur verursacht werden.
Das System muss eine breite Netzwerkvariation tolerieren (The system must tolerate wide network variation)
Ein grundlegendes Ziel des Internet-Designs ist es, eine breite Palette von Netzwerkeigenschaften zu tolerieren, einschließlich Bandbreite, Latenz, Paketverlust, Paketneuanordnung und maximale Paketgröße. Ein weiteres Ziel ist es, Robustheit unter Nutzung der verfügbaren Bandbreite auch bei einzelnen Netzwerk-, Router- und Host-Ausfällen aufrechtzuerhalten. Schließlich ist das Ziel vollständige offene Systeminteroperabilität: Internet-Router müssen in der Lage sein, robust und effektiv mit anderen Routern oder Internet-Hosts über verschiedene Internet-Pfade zu interoperieren.
Implementierer entwerfen manchmal für weniger ehrgeizige Ziele. Zum Beispiel ist eine LAN-Umgebung normalerweise freundlicher als das gesamte Internet. LANs haben geringe Paketverluste und Latenz und ordnen Pakete nicht neu an. Einige Hersteller haben Implementierungen ausgeliefert, die für einfache LAN-Umgebungen ausreichend, aber für allgemeine Interoperabilität nicht gut geeignet sind. Hersteller rechtfertigen solche Produkte als wirtschaftlich für den eingeschränkten LAN-Markt. Isolierte LANs bleiben jedoch selten lange isoliert. Sie werden bald miteinander verbunden, mit dem organisationsweiten Internet verbunden und schließlich mit dem globalen Internetsystem verbunden. Letztendlich dienen unvollständige oder nicht standardkonforme Router weder Kunden noch Herstellern.
Die Anforderungen in diesem Dokument sind für voll funktionsfähige Router konzipiert. Ein vollständig konformer Router kann in fast jedem Teil des Internets verwendet werden.