Appendix A. OSPF Data Formats
A. OSPF-Datenformate (OSPF data formats)
Dieser Anhang beschreibt das Format der OSPF-Protokollpakete und der OSPF-LSAs. Das OSPF-Protokoll läuft direkt über der IP-Netzwerkschicht. Bevor Datenformate beschrieben werden, werden die Details der OSPF-Kapselung erklärt.
Als Nächstes wird das OSPF-Optionsfeld beschrieben. Dieses Feld beschreibt verschiedene Fähigkeiten, die von Teilen des OSPF-Routing-Domänen möglicherweise unterstützt werden oder auch nicht. Das OSPF-Optionsfeld ist in OSPF-Hello-Paketen, Database-Description-Paketen und in OSPF-LSAs enthalten.
Die OSPF-Paketformate sind in Abschnitt A.3 im Detail dargestellt. Eine Beschreibung der OSPF-LSAs erscheint in Abschnitt A.4.
A.1 Kapselung von OSPF-Paketen (Encapsulation of OSPF packets)
OSPF läuft direkt über der Netzwerkschicht des Internet-Protokolls. OSPF-Pakete werden daher ausschließlich durch IP- und lokale Datenlink-Header gekapselt.
OSPF definiert keine Möglichkeit, seine Protokollpakete zu fragmentieren, und verlässt sich beim Senden von Paketen, die größer als die Netzwerk-MTU sind, auf die IP-Fragmentierung. Falls nötig, kann die Länge von OSPF-Paketen bis zu 65.535 Bytes betragen (einschließlich IP-Header). Die OSPF-Pakettypen, die voraussichtlich groß sind (Database-Description-Pakete, Link-State-Request-, Link-State-Update- und Link-State-Acknowledgment-Pakete), können normalerweise ohne Funktionsverlust in mehrere separate Protokollpakete aufgeteilt werden. Dies wird empfohlen; IP-Fragmentierung sollte nach Möglichkeit vermieden werden. Nach dieser Überlegung sollte versucht werden, die Größe von OSPF-Paketen, die über virtuelle Links gesendet werden, auf 576 Bytes zu begrenzen, sofern keine Path-MTU-Discovery durchgeführt wird (siehe [Ref22]).
Die weiteren wichtigen Merkmale der IP-Kapselung von OSPF sind:
o Verwendung von IP-Multicast. Einige OSPF-Nachrichten werden per Multicast gesendet, wenn sie über Broadcast-Netzwerke übertragen werden. Es werden zwei unterschiedliche IP-Multicast-Adressen verwendet. An diese Multicast-Adressen gesendete Pakete sollten niemals weitergeleitet werden; sie sind nur für einen einzelnen Hop gedacht. Um sicherzustellen, dass diese Pakete nicht mehrere Hops zurücklegen, muss ihr IP-TTL auf 1 gesetzt werden.
AllSPFRouters
Diese Multicast-Adresse wurde mit dem Wert 224.0.0.5 belegt. Alle Router, die OSPF ausführen, sollten darauf vorbereitet sein, an diese Adresse gesendete Pakete zu empfangen. Hello-Pakete werden immer an dieses Ziel gesendet. Außerdem werden bestimmte OSPF-Protokollpakete während des Flooding-Verfahrens an diese Adresse gesendet.
AllDRouters
Diese Multicast-Adresse wurde mit dem Wert 224.0.0.6 belegt. Sowohl der Designated Router als auch der Backup Designated Router müssen darauf vorbereitet sein, an diese Adresse gerichtete Pakete zu empfangen. Bestimmte OSPF-Protokollpakete werden während des Flooding-Verfahrens an diese Adresse gesendet.
o OSPF ist die IP-Protokollnummer 89. Diese Nummer wurde beim Network Information Center registriert. Die Zuweisungen von IP-Protokollnummern sind in [Ref11] dokumentiert.
o Alle OSPF-Routing-Protokollpakete werden mit dem normalen TOS-Wert für Dienst binary 0000 gesendet, der in [Ref12] definiert ist.
o Routing-Protokollpakete werden mit der IP-Präzedenz (precedence) Internetwork Control gesendet. OSPF-Protokollpakete sollten bei Sende- und Empfangsseite Vorrang vor regulär IP-Datenverkehr erhalten. Das Setzen des IP-Präzedenzfeldes im IP-Header auf Internetwork Control [Ref5] kann helfen, dieses Ziel zu erreichen.
A.2 Das Optionsfeld (The Options field)
Das OSPF-Optionsfeld ist in OSPF-Hello-Paketen, Database-Description-Paketen und allen LSAs vorhanden. Das Optionsfeld ermöglicht es OSPF-Routern, optionale Fähigkeiten zu unterstützen (oder nicht zu unterstützen) und ihr Fähigkeitsniveau anderen OSPF-Routern mitzuteilen. Durch diesen Mechanismus können Router mit unterschiedlichen Fähigkeiten innerhalb einer OSPF-Routing-Domäne gemischt werden.
Wenn es in Hello-Paketen verwendet wird, erlaubt das Optionsfeld einem Router, einen Nachbarn wegen einer Fähigkeitsinkompatibilität (capability mismatch) abzulehnen. Alternativ kann ein Router, wenn Fähigkeiten in Database-Description-Paketen ausgetauscht werden, entscheiden, bestimmte LSAs einem Nachbarn wegen dessen eingeschränkter Funktionalität nicht weiterzuleiten. Schließlich ermöglicht das Aufführen von Fähigkeiten in LSAs Routern, den Datenverkehr an Router mit eingeschränkter Funktionalität vorbei zu leiten, indem sie von Teilen der Routing-Tabellen-Berechnung ausgeschlossen werden.
Fünf Bits des OSPF-Optionsfeldes wurden zugewiesen, obwohl nur eines (das E-Bit) in diesem Memo vollständig beschrieben wird. Jedes Bit wird unten kurz beschrieben. Router sollten nicht erkannte Bits im Optionsfeld zurücksetzen (d. h. löschen), wenn sie Hello-Pakete oder Database-Description-Pakete senden und wenn sie LSAs erzeugen (originating). Umgekehrt sollten Router, die nicht erkannte Options-Bits in empfangenen Hello-Paketen, Database-Description-Paketen oder LSAs antreffen, die Fähigkeit ignorieren und das Paket/LSA normal verarbeiten.
+------------------------------------+
| * | * | DC | EA | N/P | MC | E | * |
+------------------------------------+
The Options field
E-bit
Dieses Bit beschreibt die Art, wie AS-external-LSAs gefloodet werden, wie in den Abschnitten 3.6, 9.5, 10.8 und 12.1.2 dieses Memos beschrieben.
MC-bit
Dieses Bit beschreibt, ob IP-Multicast-Datagramme gemäß den Spezifikationen in [Ref18] weitergeleitet werden.
N/P-bit
Dieses Bit beschreibt den Umgang mit Typ-7-LSAs, wie in [Ref19] festgelegt.
EA-bit
Dieses Bit beschreibt die Bereitschaft des Routers, External-Attributes-LSAs zu empfangen und weiterzuleiten, wie in [Ref20] festgelegt.
DC-bit
Dieses Bit beschreibt den Umgang des Routers mit Demand Circuits, wie in [Ref21] festgelegt.
A.3 OSPF-Paketformate (OSPF Packet Formats)
Es gibt fünf verschiedene OSPF-Pakettypen. Alle OSPF-Pakettypen beginnen mit einem Standard-Header von 24 Bytes. Dieser Header wird zuerst beschrieben. Jeder Pakettyp wird dann in einem folgenden Abschnitt beschrieben. In diesen Abschnitten wird die Unterteilung jedes Pakets in Felder dargestellt, und anschließend werden die Felddefinitionen aufgezählt.
Alle OSPF-Pakettypen (außer den OSPF-Hello-Paketen) befassen sich mit Listen von LSAs. Beispielsweise implementieren Link-State-Update-Pakete das Flooding von LSAs über die gesamte OSPF-Routing-Domäne. Aus diesem Grund können OSPF-Protokollpakete nicht analysiert werden, es sei denn, das Format der LSAs ist ebenfalls verstanden. Das Format der LSAs ist in Abschnitt A.4 beschrieben.
Die Empangsverarbeitung von OSPF-Paketen ist in Abschnitt 8.2 im Detail dargestellt. Das Senden von OSPF-Paketen wird in Abschnitt 8.1 erklärt.
A.3.1 Der OSPF-Paket-Header (The OSPF packet header)
Jedes OSPF-Paket beginnt mit einem Standard-Header von 24 Bytes. Dieser Header enthält alle Informationen, die notwendig sind, um zu bestimmen, ob das Paket für eine weitere Verarbeitung akzeptiert werden sollte. Diese Bestimmung ist in Abschnitt 8.2 der Spezifikation beschrieben.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | Type | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version #
Die OSPF-Versionsnummer. Diese Spezifikation dokumentiert Version 2 des Protokolls.
Type
Die OSPF-Pakettypen sind wie folgt. Einzelheiten siehe Abschnitte A.3.2 bis A.3.6.
Type Description
________________________________
1 Hello
2 Database Description
3 Link State Request
4 Link State Update
5 Link State Acknowledgment
Packet length
Die Länge des OSPF-Protokollpakets in Bytes. Diese Länge umfasst den Standard-OSPF-Header.
Router ID
Die Router-ID der Quelle des Pakets.
Area ID
Eine 32-Bit-Zahl, die die Area identifiziert, zu der dieses Paket gehört. Alle OSPF-Pakete sind mit einer einzelnen Area verknüpft. Die meisten legen nur einen einzelnen Hop zurück. Pakete, die über einen virtuellen Link übertragen werden, sind mit der Backbone-Area-ID 0.0.0.0 gekennzeichnet.
Checksum
Die Standard-IP-Prüfsumme des gesamten Paketinhalts, beginnend mit dem OSPF-Paket-Header, aber unter Ausschluss des 64-Bit-Authentifizierungsfeldes. Diese Prüfsumme wird als das 16-Bit-Einerkomplement der Einerkomplement-Summe aller 16-Bit-Wörter im Paket berechnet, wobei das Authentifizierungsfeld ausgenommen ist. Falls die Paketlänge keine ganzzahlige Anzahl von 16-Bit-Wörtern ist, wird das Paket vor der Prüfsummenberechnung mit einem Null-Byte aufgefüllt. Die Prüfsumme gilt als Teil des Paket-Authentifizierungsverfahrens; für einige Authentifizierungstypen wird die Prüfsummenberechnung weggelassen.
AuType
Identifiziert das für das Paket zu verwendende Authentifizierungsverfahren. Authentifizierung wird im Anhang D der Spezifikation erörtert. Einen Verzeichnis der derzeit definierten Authentifizierungstypen finden Sie in Anhang D.
Authentication
Ein 64-Bit-Feld zur Verwendung durch das Authentifizierungsschema. Einzelheiten siehe Anhang D.
A.3.2 Das Hello-Paket (The Hello packet)
Hello-Pakete sind der OSPF-Pakettyp 1. Diese Pakete werden periodisch auf allen Interfaces (einschließlich virtueller Links) gesendet, um Nachbarschaftsbeziehungen (neighbor relationships) aufzubauen und aufrechtzuerhalten. Zusätzlich werden Hello-Pakete auf den physischen Netzwerken per Multicast gesendet, die eine Multicast- oder Broadcast-Fähigkeit besitzen, was die dynamische Entdeckung benachbarter Router ermöglicht.
Alle mit einem gemeinsamen Netzwerk verbundenen Router müssen sich auf bestimmte Parameter einigen (Network mask, HelloInterval und RouterDeadInterval). Diese Parameter sind in Hello-Paketen enthalten, sodass Unterschiede die Bildung von Nachbarschaftsbeziehungen behindern können. Eine detaillierte Erklärung der Empfangsverarbeitung für Hello-Pakete wird in Abschnitt 10.5 gegeben. Das Senden von Hello-Paketen wird in Abschnitt 9.5 behandelt.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | 1 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HelloInterval | Options | Rtr Pri |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RouterDeadInterval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Designated Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Backup Designated Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Network mask
Die mit diesem Interface verbundene Netzwerkmaske. Wenn das Interface beispielsweise mit einem Klasse-B-Netzwerk verbunden ist, dessen drittes Byte für Subnetting verwendet wird, ist die Netzwerkmaske 0xffffff00.
Options
Die vom Router unterstützten optionalen Fähigkeiten, wie in Abschnitt A.2 dokumentiert.
HelloInterval
Die Anzahl der Sekunden zwischen den Hello-Paketen dieses Routers.
Rtr Pri
Die Router-Priorität (Router Priority) dieses Routers. Wird bei der Wahl des (Backup) Designated Router verwendet. Ist sie auf 0 gesetzt, ist der Router nicht berechtigt, (Backup) Designated Router zu werden.
RouterDeadInterval
Die Anzahl der Sekunden, bevor ein stiller Router als ausgefallen (down) erklärt wird.
Designated Router
Die Identität des Designated Router für dieses Netzwerk, aus der Sicht des sendenden Routers. Der Designated Router wird hier durch seine IP-Interface-Adresse im Netzwerk identifiziert. Auf 0.0.0.0 gesetzt, falls kein Designated Router vorhanden ist.
Backup Designated Router
Die Identität des Backup Designated Router für dieses Netzwerk, aus der Sicht des sendenden Routers. Der Backup Designated Router wird hier durch seine IP-Interface-Adresse im Netzwerk identifiziert. Auf 0.0.0.0 gesetzt, falls kein Backup Designated Router vorhanden ist.
Neighbor
Die Router-IDs jedes Routers, von dem gültige Hello-Pakete kürzlich im Netzwerk gesehen wurden. Kürzlich bedeutet in den letzten RouterDeadInterval Sekunden.
A.3.3 Das Database-Description-Paket (The Database Description packet)
Database-Description-Pakete sind der OSPF-Pakettyp 2. Diese Pakete werden ausgetauscht, wenn eine Adjacency initialisiert wird. Sie beschreiben den Inhalt der Link-State-Datenbank. Es können mehrere Pakete verwendet werden, um die Datenbank zu beschreiben. Zu diesem Zweck wird ein Poll-Response-Verfahren verwendet. Einer der Router wird als Master, der andere als Slave designiert. Der Master sendet Database-Description-Pakete (Polls), die durch vom Slave gesendete Database-Description-Pakete (Responses) bestätigt werden. Die Responses werden über die DD-Sequenznummern der Pakete mit den Polls verknüpft.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | 2 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface MTU | Options |0|0|0|0|0|I|M|MS
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DD sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- An LSA Header -+
| |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Das Format des Database-Description-Pakets ist sowohl dem Link-State-Request- als auch dem Link-State-Acknowledgment-Paket sehr ähnlich. Der Hauptteil aller drei ist eine Liste von Elementen, wobei jedes Element ein Stück der Link-State-Datenbank beschreibt. Das Senden von Database-Description-Paketen ist in Abschnitt 10.8 dokumentiert. Der Empfang von Database-Description-Paketen ist in Abschnitt 10.6 dokumentiert.
Interface MTU
Die Größe in Bytes des größten IP-Datagramms, das ohne Fragmentierung über das zugehörige Interface gesendet werden kann. Die MTUs gängiger Internet-Linktypen finden sich in Tabelle 7-1 von [Ref22]. Interface MTU sollte in Database-Description-Paketen, die über virtuelle Links gesendet werden, auf 0 gesetzt werden.
Options
Die vom Router unterstützten optionalen Fähigkeiten, wie in Abschnitt A.2 dokumentiert.
I-bit
Das Init-Bit. Wenn auf 1 gesetzt, ist dieses Paket das erste in der Sequenz von Database-Description-Paketen.
M-bit
Das More-Bit. Wenn auf 1 gesetzt, zeigt es an, dass weitere Database-Description-Pakete folgen.
MS-bit
Das Master/Slave-Bit. Wenn auf 1 gesetzt, zeigt es an, dass der Router während des Database-Exchange-Prozesses der Master ist. Andernfalls ist der Router der Slave.
DD sequence number
Dient zur Sequenzierung der Sammlung von Database-Description-Paketen. Der Anfangswert (angezeigt durch das gesetzte Init-Bit) sollte eindeutig sein. Die DD-Sequenznummer wird dann inkrementiert, bis die vollständige Datenbankbeschreibung gesendet wurde.
Der Rest des Pakets besteht aus einer (möglicherweise partiellen) Liste der Stücke der Link-State-Datenbank. Jede LSA in der Datenbank wird durch ihren LSA-Header beschrieben. Der LSA-Header ist in Abschnitt A.4.1 dokumentiert. Er enthält alle Informationen, die erforderlich sind, um sowohl die LSA als auch die aktuelle Instanz der LSA eindeutig zu identifizieren.
A.3.4 Das Link-State-Request-Paket (The Link State Request packet)
Link-State-Request-Pakete sind der OSPF-Pakettyp 3. Nach dem Austausch von Database-Description-Paketen mit einem benachbarten Router kann ein Router feststellen, dass Teile seiner Link-State-Datenbank veraltet sind. Das Link-State-Request-Paket wird verwendet, um die Stücke der Datenbank des Nachbarn anzufordern, die aktueller sind. Es können mehrere Link-State-Request-Pakete erforderlich sein.
Ein Router, der ein Link-State-Request-Paket sendet, hat die genaue Instanz der angeforderten Datenbankstücke im Sinn. Jede Instanz ist durch ihre LS-Sequenznummer, LS-Prüfsumme und LS-Age definiert, obwohl diese Felder nicht im Link-State-Request-Paket selbst angegeben sind. Der Router kann als Antwort noch aktuellere Instanzen empfangen.
Das Senden von Link-State-Request-Paketen ist in Abschnitt 10.9 dokumentiert. Der Empfang von Link-State-Request-Paketen ist in Abschnitt 10.7 dokumentiert.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | 3 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Jede angeforderte LSA wird durch ihren LS-Typ, Link-State-ID und Advertising Router spezifiziert. Dies identifiziert die LSA eindeutig, aber nicht ihre Instanz. Link-State-Request-Pakete werden als Anforderungen für die aktuellste Instanz (was auch immer das sein mag) verstanden.
A.3.5 Das Link-State-Update-Paket (The Link State Update packet)
Link-State-Update-Pakete sind der OSPF-Pakettyp 4. Diese Pakete implementieren das Flooding von LSAs. Jedes Link-State-Update-Paket trägt eine Sammlung von LSAs einen Hop weiter von ihrem Ursprung weg. Mehrere LSAs können in einem einzelnen Paket enthalten sein.
Link-State-Update-Pakete werden per Multicast auf den physischen Netzwerken gesendet, die Multicast/Broadcast unterstützen. Um das Flooding-Verfahren zuverlässig zu machen, werden gefloodete LSAs in Link-State-Acknowledgment-Paketen bestätigt. Falls eine erneute Übertragung bestimmter LSAs notwendig ist, werden die erneut übertragenen LSAs immer direkt an den Nachbarn gesendet. Weitere Informationen zum zuverlässigen Flooding von LSAs finden Sie in Abschnitt 13.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | 4 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # LSAs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- +-+
| LSAs |
+- +-+
| ... |
# LSAs
Die Anzahl der in diesem Update enthaltenen LSAs.
Der Hauptteil des Link-State-Update-Pakets besteht aus einer Liste von LSAs. Jede LSA beginnt mit einem gemeinsamen 20-Byte-Header, der in Abschnitt A.4.1 beschrieben wird. Detaillierte Formate der verschiedenen LSA-Typen sind in Abschnitt A.4 beschrieben.
A.3.6 Das Link-State-Acknowledgment-Paket (The Link State Acknowledgment packet)
Link-State-Acknowledgment-Pakete sind der OSPF-Pakettyp 5. Um das Flooding von LSAs zuverlässig zu machen, werden gefloodete LSAs explizit bestätigt. Diese Bestätigung wird durch das Senden und Empfangen von Link-State-Acknowledgment-Paketen erreicht. Mehrere LSAs können in einem einzelnen Link-State-Acknowledgment-Paket bestätigt werden.
Je nach Zustand des sendenden Interfaces und dem Sender des entsprechenden Link-State-Update-Pakets wird ein Link-State-Acknowledgment-Paket entweder an die Multicast-Adresse AllSPFRouters, an die Multicast-Adresse AllDRouters oder als Unicast gesendet. Das Senden von Link-State-Acknowledgment-Paketen ist in Abschnitt 13.5 dokumentiert. Der Empfang von Link-State-Acknowledgment-Paketen ist in Abschnitt 13.7 dokumentiert.
Das Format dieses Pakets ähnelt dem des Data-Description-Pakets. Der Hauptteil beider Pakete ist einfach eine Liste von LSA-Headern.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | 5 | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- An LSA Header -+
| |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Jede bestätigte LSA wird durch ihren LSA-Header beschrieben. Der LSA-Header ist in Abschnitt A.4.1 dokumentiert. Er enthält alle Informationen, die erforderlich sind, um sowohl die LSA als auch die aktuelle Instanz der LSA eindeutig zu identifizieren.