Zum Hauptinhalt springen

6.1.4. Map-Reply Message Format (Map-Reply-Nachrichtenformat)

6.1.4. Map-Reply Message Format (Map-Reply-Nachrichtenformat)

        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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=2 |P|E|S| Reserved | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

R | Locator Count | EID mask-len | ACT |A| Reserved |

   e   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

c | Rsvd | Map-Version Number | EID-Prefix-AFI |

   o   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

r | EID-Prefix |

   d   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /| Priority | Weight | M Priority | M Weight |
| L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o | Unused Flags |L|p|R| Loc-AFI |
| c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| \| Locator |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Paketfeldbeschreibungen:

Type: 2 (Map-Reply)

P: Dies ist das Probe-Bit, das anzeigt, dass das Map-Reply eine Antwort auf einen Locator-Erreichbarkeitssondierungs-Map-Request ist. Das Feld 'Nonce' MUSS eine Kopie des Nonce-Werts aus dem ursprünglichen Map-Request enthalten. Siehe Abschnitt 6.3.2 für weitere Details.

E: Dieses Bit zeigt an, dass der ETR, der diese Map-Reply-Nachricht sendet, bekannt gibt, dass die Site für den Echo-Nonce-Locator-Erreichbarkeitsalgorithmus aktiviert ist. Siehe Abschnitt 6.3.1 für weitere Details.

S: Dies ist das Sicherheitsbit. Wenn es auf 1 gesetzt ist, werden die folgenden Authentifizierungsinformationen am Ende des Map-Reply angehängt. Das detaillierte Format des Authentication Data Content ist Gegenstand weiterer Untersuchungen.

     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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AD Type | Authentication Data Content . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Reserved: Dieses Feld MUSS bei der Übertragung auf 0 gesetzt werden und MUSS beim Empfang ignoriert werden.

Record Count: Dies ist die Anzahl der Datensätze in dieser Antwortnachricht. Ein Datensatz besteht aus dem oben als 'Record' gekennzeichneten Teil des Pakets und erscheint so oft wie Record Count.

Nonce: Dies ist ein 24-Bit-Wert, der in einem Data-Probe-Paket gesetzt wird, oder ein 64-Bit-Wert aus dem Map-Request, der in diesem 'Nonce'-Feld des Map-Reply wiedergegeben wird. Wenn ein 24-Bit-Wert bereitgestellt wird, befindet er sich in den niederwertigen 64 Bits des 'Nonce'-Felds.

Record TTL: Dies ist die Zeit in Minuten, die der Empfänger des Map-Reply das Mapping speichern wird. Wenn die TTL 0 ist, SOLLTE der Eintrag sofort aus dem Cache entfernt werden. Wenn der Wert 0xffffffff ist, kann der Empfänger lokal entscheiden, wie lange das Mapping gespeichert werden soll.

Locator Count: Dies ist die Anzahl der Locator-Einträge. Ein Locator-Eintrag umfasst das, was oben als 'Loc' gekennzeichnet ist. Die Locator-Anzahl kann 0 sein, was anzeigt, dass es keine Locators für das EID-Prefix gibt.

EID mask-len: Dies ist die Maskenlänge für das EID-Prefix.

ACT: Dieses 3-Bit-Feld beschreibt Negative Map-Reply-Aktionen. In jedem anderen Nachrichtentyp werden diese Bits auf 0 gesetzt und beim Empfang ignoriert. Diese Bits werden nur verwendet, wenn das Feld 'Locator Count' auf 0 gesetzt ist. Die Aktionsbits werden nur in Map-Reply-Nachrichten codiert. Die definierten Aktionen werden von einem ITR oder PITR verwendet, wenn eine Ziel-EID mit einem negativen Map-Cache-Eintrag übereinstimmt. Nicht zugewiesene Werte sollten die Erstellung eines Map-Cache-Eintrags verursachen, und wenn Pakete mit diesem negativen Cache-Eintrag übereinstimmen, werden sie verworfen. Die derzeit zugewiesenen Werte sind:

(0) No-Action: Der Map-Cache wird am Leben erhalten, und es erfolgt keine Paketkapselung.

(1) Natively-Forward: Das Paket wird nicht gekapselt oder verworfen, sondern nativ weitergeleitet.

(2) Send-Map-Request: Das Paket löst das Senden eines Map-Request aus.

(3) Drop: Ein Paket, das mit diesem Map-Cache-Eintrag übereinstimmt, wird verworfen. Eine ICMP Destination Unreachable-Nachricht SOLLTE gesendet werden.

A: Das Authoritative-Bit wird beim Senden immer von einem ETR auf 1 gesetzt. Wenn ein Map-Server für eine LISP-Site einen Proxy-Map-Reply [RFC6833] durchführt, wird das Authoritative-Bit auf 0 gesetzt. Dies zeigt anfragenden ITRs an, dass das Map-Reply nicht von einem LISP-Knoten stammt, der an der Site verwaltet wird, die das EID-Prefix besitzt.

Map-Version Number: Wenn dieser 12-Bit-Wert ungleich Null ist, informiert der Map-Reply-Absender den ITR über die Versionsnummer für den im Map-Reply enthaltenen EID-Datensatz. Der ETR kann diese Nummer intern zuweisen, MUSS diesen Wert jedoch mit anderen ETRs für die Site koordinieren. Wenn dieser Wert 0 ist, werden keine Versionsinformationen übermittelt. Die Map-Version-Nummer kann in Map-Request- und Map-Register-Nachrichten enthalten sein. Siehe Abschnitt 6.6.3 für weitere Details.

EID-Prefix-AFI: Adressfamilie des EID-Prefix gemäß [AFI].

EID-Prefix: Dieses Präfix ist 4 Oktette für eine IPv4-Adressfamilie und 16 Oktette für eine IPv6-Adressfamilie.

Priority: Jedem RLOC wird eine Unicast-Priorität zugewiesen. Niedrigere Werte sind vorzuziehen. Wenn mehrere RLOCs dieselbe Priorität haben, KÖNNEN sie in einer Load-Split-Weise verwendet werden. Ein Wert von 255 bedeutet, dass der RLOC NICHT für Unicast-Weiterleitung verwendet werden DARF.

Weight: Wenn die Prioritäten für mehrere RLOCs gleich sind, gibt das Gewicht an, wie der Unicast-Verkehr zwischen ihnen aufgeteilt werden soll. Das Gewicht wird als relatives Gewicht der gesamten Unicast-Pakete codiert, die mit dem Mapping-Eintrag übereinstimmen. Wenn es beispielsweise 4 Locators in einem Locator-Set gibt, wobei die zugewiesenen Gewichte 30, 20, 20 und 10 sind, erhält der erste Locator 37,5% des Verkehrs, der 2. und 3. Locator erhalten 25% des Verkehrs, und der 4. Locator erhält 12,5% des Verkehrs. Wenn alle Gewichte für ein Locator-Set gleich sind, entscheidet der Empfänger des Map-Reply, wie der Verkehr aufgeteilt werden soll. Siehe Abschnitt 6.5 für einen vorgeschlagenen Hash-Algorithmus zur Lastverteilung über Locators mit derselben Priorität und gleichen Gewichtswerten.

M Priority: Jedem RLOC wird eine Multicast-Priorität zugewiesen, die von einem ETR an einer Empfänger-Multicast-Site verwendet wird, um einen ITR an einer Quell-Multicast-Site für den Aufbau von Multicast-Verteilungsbäumen auszuwählen. Ein Wert von 255 bedeutet, dass der RLOC NICHT zum Beitritt zu einem Multicast-Verteilungsbaum verwendet werden DARF. Weitere Details finden Sie in [RFC6831].

M Weight: Wenn die Prioritäten für mehrere RLOCs gleich sind, gibt das Gewicht an, wie der Aufbau von Multicast-Verteilungsbäumen über mehrere ITRs ausgeglichen werden soll. Das Gewicht wird als relatives Gewicht (ähnlich den Unicast-Gewichten) der Gesamtzahl der Bäume codiert, die zur durch das EID-Prefix identifizierten Quellsite aufgebaut werden. Wenn alle Gewichte für ein Locator-Set gleich sind, entscheidet der Empfänger des Map-Reply, wie der Multicast-Zustand über ITRs verteilt werden soll. Weitere Details finden Sie in [RFC6831].

Unused Flags: Diese werden beim Senden auf 0 gesetzt und beim Empfang ignoriert.

L: Wenn dieses Bit gesetzt ist, wird der Locator als lokaler Locator für den ETR gekennzeichnet, der das Map-Reply sendet. Wenn ein Map-Server einen Proxy-Map-Reply [RFC6833] für eine LISP-Site durchführt, wird das L-Bit für alle Locators in diesem Locator-Set auf 0 gesetzt.

p: Wenn dieses Bit gesetzt ist, informiert ein ETR den RLOC-Probing-ITR, dass die Locator-Adresse, für die dieses Bit gesetzt ist, diejenige ist, die RLOC-geprobt wird, und KANN sich von der Quelladresse des Map-Reply unterscheiden. Ein ITR, der einen bestimmten Locator RLOC-probt, MUSS diesen Locator verwenden, um die Datenstruktur abzurufen, die verwendet wird, um die Tatsache zu speichern, dass der Locator erreichbar ist. Das p-Bit wird für einen einzelnen Locator im selben Locator-Set gesetzt. Wenn eine Implementierung fälschlicherweise mehr als ein p-Bit setzt, MUSS der Empfänger des Map-Reply den ersten Locator auswählen. Das p-Bit DARF NICHT für Locator-Set-Datensätze gesetzt werden, die in Map-Request- und Map-Register-Nachrichten gesendet werden.

R: Dies wird gesetzt, wenn der Absender eines Map-Reply eine Route zum Locator im Locator-Datensatz hat. Der Empfänger kann dies nützlich finden, um zu wissen, ob der Locator aktiv ist, aber nicht unbedingt aus der Sicht des Empfängers erreichbar ist. Siehe auch Abschnitt 6.4 für eine andere Art, wie das R-Bit verwendet werden kann.

Locator: Dies ist eine IPv4- oder IPv6-Adresse (wie durch das Feld 'Loc-AFI' codiert), die einem ETR zugewiesen ist. Beachten Sie, dass die Ziel-RLOC-Adresse eine Anycast-Adresse sein KANN. Eine Quell-RLOC kann ebenfalls eine Anycast-Adresse sein. Die Quell- oder Ziel-RLOC DARF NICHT die Broadcast-Adresse (255.255.255.255 oder eine dem Router bekannte Subnetz-Broadcast-Adresse) sein und DARF NICHT eine Link-Local-Multicast-Adresse sein. Die Quell-RLOC DARF NICHT eine Multicast-Adresse sein. Die Ziel-RLOC SOLLTE eine Multicast-Adresse sein, wenn sie von einer Multicast-Ziel-EID gemappt wird.