3. Link Layer (Verbindungsschicht)
3. Verbindungsschicht (Link Layer)
[INTRO:1] behandelt Verbindungsschichtstandards (Implementierung von IP über verschiedene Verbindungsschichten, ARP usw.), und dieses Dokument geht davon aus, dass Verbindungsschichtmaterial in einem separaten Verbindungsschicht-Anforderungsdokument behandelt wird. Das Verbindungsschicht-Anforderungsdokument gilt sowohl für Hosts als auch für Router. Daher ersetzt dieses Dokument nicht die Abschnitte von [INTRO:1], die Verbindungsschichtprobleme behandeln.
3.1 Einleitung
Router haben im Wesentlichen dieselben Verbindungsschicht-Protokollanforderungen wie andere Arten von Internet-Systemen. Diese Anforderungen sind in Kapitel 3 von Requirements for Internet Gateways [INTRO:1] angegeben. Router MÜSSEN diesen Anforderungen entsprechen und SOLLTEN deren Empfehlungen befolgen. Da einige Materialien in diesem Dokument etwas veraltet sind, werden im Folgenden einige zusätzliche Anforderungen und Erläuterungen aufgeführt.
DISKUSSION
Es wird erwartet, dass die Internet-Gemeinschaft einen Internet-Verbindungsschicht-Anforderungsstandard erstellt, der dieses Kapitel und das Kapitel mit dem Titel „INTERNET LAYER PROTOCOLS" in [INTRO:1] ersetzt.
3.2 Verbindungsschicht/Internetschicht-Schnittstelle (Link/Internet Layer Interface)
Dieses Dokument versucht nicht, die Schnittstelle zwischen der Verbindungsschicht und den oberen Schichten zu spezifizieren. Andere Teile dieses Dokuments, insbesondere Kapitel 5, weisen jedoch darauf hin, dass verschiedene Arten von Informationen diese Schichtgrenze überschreiten müssen.
In diesem Abschnitt werden folgende Definitionen verwendet:
Physische Quelladresse (Source physical address)
Die physische Quelladresse ist die Verbindungsschichtadresse des Hosts oder Routers, von dem das Paket empfangen wurde.
Physische Zieladresse (Destination physical address)
Die physische Zieladresse ist die Verbindungsschichtadresse, an die das Paket gesendet wurde.
Für jedes empfangene Paket müssen folgende Informationen von der Verbindungsschicht an die Netzwerkschicht übergeben werden:
(1) IP-Paket [5.2.2]
(2) Länge des Datenteils des Verbindungsschicht-Frames (d. h. ohne den Verbindungsschicht-Frame) [5.2.2]
(3) Identifikation der physischen Schnittstelle, über die das IP-Paket empfangen wurde [5.2.3], und
(4) Klassifizierung der physischen Zieladresse des Pakets als Verbindungsschicht-Unicast, -Broadcast oder -Multicast [4.3.2], [5.3.4]
Darüber hinaus SOLLTE die Verbindungsschicht Folgendes bereitstellen:
(5) Physische Quelladresse
Für jedes zu sendende Paket müssen folgende Informationen von der Netzwerkschicht an die Verbindungsschicht übergeben werden:
(1) IP-Paket [5.2.1]
(2) Länge des IP-Pakets [5.2.1]
(3) Physische Zielschnittstelle [5.2.1]
(4) IP-Adresse des nächsten Hops [5.2.1]
Darüber hinaus SOLLTE die Netzwerkschicht Folgendes bereitstellen:
(5) Verbindungsschicht-Prioritätswert [5.3.3.2]
Wenn ein zu sendendes Paket einen verbindungsschichtprioritätsbezogenen Fehler verursacht, MUSS die Verbindungsschicht die Netzwerkschicht benachrichtigen [5.3.3.3].
3.3 Spezifische Probleme (Specific Issues)
3.3.1 Trailer-Kapselung (Trailer Encapsulation)
Router, die sich mit 10-Megabit-Ethernet verbinden können, KÖNNEN Ethernet-Pakete empfangen und weiterleiten, die die in [LINK:1] beschriebene Trailer-Kapselung verwenden. Router SOLLTEN jedoch keine Trailer-gekapselten Pakete initiieren. Router DÜRFEN NICHT Trailer-gekapselte Pakete initiieren, ohne zunächst mithilfe der in [INTRO:2] beschriebenen Mechanismen zu bestätigen, dass das direkte Ziel des Pakets Trailer-gekapselte Pakete empfangen kann und bereit ist, diese zu empfangen. Router SOLLTEN (mithilfe dieser Mechanismen) nicht zustimmen, Trailer-gekapselte Pakete zu empfangen.
3.3.2 Address Resolution Protocol - ARP (Adressauflösungsprotokoll)
Router, die ARP implementieren, MÜSSEN den Anforderungen von [INTRO:2] entsprechen und SOLLTEN unbedingt konform sein.
Die Verbindungsschicht DARF NICHT einen Destination-Unreachable-Fehler (Ziel nicht erreichbar) an IP melden, nur weil kein ARP-Cache-Eintrag für das Ziel vorhanden ist. Während der Ausführung einer ARP-Anfrage/Antwort-Sequenz SOLLTEN einige wenige Datagramme vorübergehend in die Warteschlange gestellt werden, und nur wenn sich dies als nutzlos erweist, SOLLTE mit einem Destination-Unreachable auf eines der in der Warteschlange befindlichen Datagramme geantwortet werden.
Router DÜRFEN NICHT einer ARP-Antwort vertrauen, die behauptet, dass die Verbindungsschichtadresse eines anderen Hosts oder Routers eine Broadcast- oder Multicast-Adresse ist.
3.3.3 Ethernet und 802.3 Koexistenz (Ethernet and 802.3 Coexistence)
Router, die sich mit 10-Megabit-Ethernet verbinden können, MÜSSEN den Ethernet-Anforderungen von [INTRO:2] entsprechen und SOLLTEN unbedingt konform sein.
3.3.4 Maximum Transmission Unit - MTU (Maximale Übertragungseinheit)
Die MTU jeder logischen Schnittstelle MUSS innerhalb des gültigen MTU-Bereichs der Schnittstelle konfigurierbar sein.
Viele Verbindungsschichtprotokolle definieren eine maximale Frame-Größe, die gesendet werden kann. In diesem Fall DARF der Router keine MTU-Einstellung zulassen, die das Senden von Frames ermöglichen würde, die größer sind als das Verbindungsschichtprotokoll erlaubt. Der Router SOLLTE jedoch in der Lage sein, Pakete zu empfangen, die so groß wie die maximale Frame-Größe sind, auch wenn diese größer als die MTU ist.
DISKUSSION
Beachten Sie, dass dies eine strengere Anforderung ist als die, die [INTRO:2] an Hosts stellt. [INTRO:2] erfordert, dass die MTU jeder physischen Schnittstelle konfigurierbar ist.
Wenn ein Netzwerk eine MTU verwendet, die kleiner als die maximale Frame-Größe der Verbindungsschicht ist, kann der Router Pakete empfangen, die größer als die MTU sind, von falsch konfigurierten und nicht vollständig initialisierten Hosts. Das Robustheitsprinzip legt nahe, dass der Router diese Pakete nach Möglichkeit ordnungsgemäß empfangen SOLLTE.
3.3.5 Point-to-Point Protocol - PPP (Punkt-zu-Punkt-Protokoll)
Im Gegensatz zu [INTRO:1] gibt es im Internet tatsächlich ein standardmäßiges Punkt-zu-Punkt-Leitungsprotokoll: das Point-to-Point Protocol (PPP, Punkt-zu-Punkt-Protokoll), definiert in [LINK:2], [LINK:3], [LINK:4] und [LINK:5].
Eine Punkt-zu-Punkt-Schnittstelle ist eine Schnittstelle, die für die Übertragung von Daten über Punkt-zu-Punkt-Leitungen ausgelegt ist. Solche Schnittstellen umfassen Telefon-, Miet-, Standleitungs- oder Direktleitungen (2-Draht oder 4-Draht) und können Punkt-zu-Punkt-Kanäle oder virtuelle Schaltkreise eines gemultiplexten Interfaces (wie ISDN) verwenden. Sie verwenden normalerweise standardisierte Modem- oder Bit-Seriell-Schnittstellen (wie RS-232, RS-449 oder V.35) und verwenden synchrone oder asynchrone Taktung. Gemultiplexte Schnittstellen haben normalerweise spezielle physische Schnittstellen.
Allgemeine serielle Schnittstellen verwenden dasselbe physische Medium wie Punkt-zu-Punkt-Leitungen, unterstützen aber die Verwendung von Verbindungsschichtnetzwerken und Punkt-zu-Punkt-Verbindungen. Verbindungsschichtnetzwerke (wie X.25 oder Frame Relay) verwenden alternative IP-Verbindungsschichtspezifikationen.
Router, die Punkt-zu-Punkt- oder allgemeine serielle Schnittstellen implementieren, MÜSSEN PPP IMPLEMENTIEREN.
Alle allgemeinen seriellen Schnittstellen auf einem Router MÜSSEN PPP unterstützen. Router KÖNNEN die Konfiguration einer Leitung zur Verwendung anderer Punkt-zu-Punkt-Leitungsprotokolle als PPP ermöglichen. Punkt-zu-Punkt-Schnittstellen SOLLTEN standardmäßig PPP verwenden, wenn sie aktiviert werden, oder die Konfiguration des Verbindungsschichtprotokolls vor der Aktivierung erfordern. Allgemeine serielle Schnittstellen SOLLTEN die Konfiguration des Verbindungsschichtprotokolls vor der Aktivierung erfordern.
3.3.5.1 Einleitung
Dieser Abschnitt bietet Router-Implementierern Leitlinien, um die Interoperabilität mit anderen Routern sicherzustellen, die PPP über synchrone oder asynchrone Links verwenden.
Es ist sehr wichtig, dass Implementierer die Semantik des Optionsaushandlungsmechanismus verstehen. Optionen sind eine Möglichkeit für ein lokales Gerät, dem Remote-Peer mitzuteilen, was es vom Remote-Peer akzeptieren wird, nicht was es senden möchte. Der Remote-Peer kann entscheiden, das zu senden, was ihm am bequemsten ist, innerhalb der Menge von Optionen, die das lokale Gerät angegeben hat, akzeptieren zu können. Daher ist es völlig akzeptabel und normal, dass der Remote-Peer alle in einer LCP Configuration Request (CR) angegebenen Optionen bestätigt (ACKnowledged), selbst wenn der Remote-Peer keine dieser Optionen unterstützt. Nochmals: Optionen sind ein Mechanismus, mit dem ein Gerät dem Peer mitteilt, was es akzeptieren wird, nicht unbedingt was es senden wird.
3.3.5.2 Link Control Protocol (LCP) Optionen
Das PPP Link Control Protocol (LCP, Verbindungssteuerungsprotokoll) bietet viele Optionen, die ausgehandelt werden können. Diese Optionen umfassen unter anderem: Adress- und Steuerfeld-Komprimierung, Protokollfeld-Komprimierung, asynchrone Zeichenzuordnung, Maximum Receive Unit (MRU, maximale Empfangseinheit), Link Quality Monitoring (LQM, Verbindungsqualitätsüberwachung), Magic Number (Magische Zahl, zur Loopback-Erkennung), Password Authentication Protocol (PAP, Passwort-Authentifizierungsprotokoll), Challenge Handshake Authentication Protocol (CHAP, Challenge-Handshake-Authentifizierungsprotokoll) und 32-Bit Frame Check Sequence (FCS, Frame-Prüfsequenz).
Router KÖNNEN Adress-/Steuerfeld-Komprimierung über synchrone oder asynchrone Links verwenden. Router KÖNNEN Protokollfeld-Komprimierung über synchrone oder asynchrone Links verwenden. Router, die angeben, dass sie diese Komprimierungen akzeptieren können, MÜSSEN auch unkomprimierte PPP-Header-Informationen akzeptieren können.
DISKUSSION
Diese Optionen steuern das Erscheinungsbild des PPP-Headers. Normalerweise besteht ein PPP-Header aus Adress-, Steuerfeld- und Protokollfeldern. Die Adresse auf einer Punkt-zu-Punkt-Leitung ist 0xFF, was „Broadcast" bedeutet. Das Steuerfeld ist 0x03, was „unnummerierte Information" bedeutet. Der Protocol Identifier ist ein 2-Byte-Wert, der den Inhalt des Frame-Datenbereichs angibt. Wenn ein System Adress- und Steuerfeld-Komprimierung aushandelt, teilt es dem Peer mit, dass es PPP-Frames mit oder ohne diese Felder vor dem Header akzeptieren wird. Dies bedeutet nicht, dass der Sender Frames ohne diese Felder senden wird.
Wenn Protokollfeld-Komprimierung ausgehandelt wird, zeigt dies an, dass das System bereit ist, Frames zu empfangen, bei denen das Protokollfeld auf ein Byte komprimiert wurde, wenn dies zulässig ist. Der Sender muss dies nicht tun.
Die Verwendung von Adress-/Steuerfeld-Komprimierung ist unvereinbar mit der Verwendung von nummeriertem (zuverlässigem) PPP.
IMPLEMENTIERUNG
Einige Hardware kann keine Header-Informationen variabler Länge gut verarbeiten. In diesem Fall ist es am sinnvollsten, dass der Remote-Peer vollständige PPP-Header sendet. Eine Implementierung kann dies sicherstellen, indem sie dem Remote-Peer keine Adress-/Steuerfeld- und Protokollfeld-Komprimierungsoptionen sendet. Selbst wenn der Remote-Peer angibt, dass er komprimierte Header akzeptieren kann, muss der lokale Router keine komprimierten Header senden.
Router MÜSSEN die Asynchronous Control Character Map (ACCM, asynchrone Steuerzeichenzuordnung) für asynchrone PPP-Links aushandeln, SOLLTEN jedoch NICHT die ACCM für synchrone Links aushandeln. Wenn ein Router eine Anfrage erhält, die ACCM über einen synchronen Link aushandeln möchte, MUSS er diese Option bestätigen (ACKnowledge) und dann ignorieren.
DISKUSSION
Einige Implementierungen bieten sowohl synchrone als auch asynchrone Betriebsmodi, die denselben Code für die Optionsaushandlung verwenden. In diesem Fall kann eine oder die andere Seite die ACCM-Option über einen synchronen Link senden.
Router SOLLTEN die Maximum Receive Unit (MRU, maximale Empfangseinheit) korrekt aushandeln. Selbst wenn ein System eine MRU von weniger als 1.500 Bytes ausgehandelt hat, MUSS es in der Lage sein, 1.500-Byte-Frames zu empfangen.
Router SOLLTEN die Link Quality Monitoring (LQM, Verbindungsqualitätsüberwachung) Option aushandeln und aktivieren.
DISKUSSION
Dieses Memo legt keine Richtlinie fest, um zu bestimmen, ob die Verbindungsqualität ausreichend ist. Es ist jedoch wichtig, dass Router fehlerhafte Links deaktivieren (siehe Abschnitt [3.3.6]).
Router SOLLTEN die Magic Number (Magische Zahl) Option zur Loopback-Erkennung implementieren und aushandeln.
Router KÖNNEN Authentifizierungsoptionen unterstützen (PAP - Password Authentication Protocol, Passwort-Authentifizierungsprotokoll, und/oder CHAP - Challenge Handshake Authentication Protocol, Challenge-Handshake-Authentifizierungsprotokoll).
Router MÜSSEN die 16-Bit-CRC Frame Check Sequence (FCS, Frame-Prüfsequenz) unterstützen und KÖNNEN die 32-Bit-CRC unterstützen.
3.3.5.3 IP Control Protocol (IPCP) Optionen
Router KÖNNEN anbieten, IP-Adressaushandlung durchzuführen. Router MÜSSEN die Ablehnung (REJect) der Durchführung von IP-Adressaushandlung durch den Peer akzeptieren.
Router, die mit Linkgeschwindigkeiten von 19.200 BPS oder weniger arbeiten, SOLLTEN Van-Jacobson-Header-Komprimierung implementieren und anbieten. Router, die VJ-Komprimierung implementieren, SOLLTEN eine Verwaltungssteuerung implementieren, um sie zu aktivieren oder zu deaktivieren.
3.3.6 Schnittstellentests (Interface Testing)
Router MÜSSEN über einen Mechanismus verfügen, mit dem die Routing-Software bestimmen kann, ob eine physische Schnittstelle in der Lage ist, Pakete zu senden. Bei gemultiplexten Schnittstellen, die permanente virtuelle Schaltkreise für eine begrenzte Menge von Nachbarn öffnen, MUSS der Router auch in der Lage sein, zu bestimmen, ob ein virtueller Schaltkreis funktionsfähig ist. Router SOLLTEN über einen Mechanismus verfügen, mit dem die Routing-Software die Qualität einer physischen Schnittstelle bestimmen kann. Router MÜSSEN über einen Mechanismus verfügen, der die Routing-Software benachrichtigt, wenn eine physische Schnittstelle als Ergebnis einer Verwaltungsoperation für das Senden von Paketen verfügbar oder nicht verfügbar wird. Router MÜSSEN über einen Mechanismus verfügen, der die Routing-Software benachrichtigt, wenn erkannt wird, dass eine Verbindungsschicht-Schnittstelle aus irgendeinem Grund verfügbar oder nicht verfügbar geworden ist.
DISKUSSION
Es ist sehr wichtig, dass Router über funktionierende Mechanismen verfügen, um zu bestimmen, ob eine Netzwerkverbindung ordnungsgemäß funktioniert. Die Unfähigkeit, den Verlust einer Verbindung zu erkennen, oder das Versäumnis, geeignete Maßnahmen zu ergreifen, wenn ein Problem erkannt wird, kann zu Black Holes (Schwarzen Löchern) führen.
Die Mechanismen, die zur Erkennung von Netzwerkverbindungsproblemen verwendet werden können, variieren stark je nach verwendetem Verbindungsschichtprotokoll und Schnittstellenhardware. Das Ziel ist es, die Fähigkeit zur Fehlererkennung innerhalb der Einschränkungen der Verbindungsschicht zu maximieren.