Zum Hauptinhalt springen

4.1. Packet Flow Sequence (Paketflusssequenz)

4.1. Packet Flow Sequence (Paketflusssequenz)​

Dieser Abschnitt bietet ein Beispiel für den Unicast-Paketfluss unter den folgenden Bedingungen:

  • Quellhost "host1.abc.example.com" sendet ein Paket an "host2.xyz.example.com", genau das, was host1 tun würde, wenn die Site LISP nicht verwenden würde.

  • Jede Site ist Multihomed, sodass jeder Tunnel-Router eine Adresse (RLOC) hat, die aus dem Dienstanbieter-Adressblock für jeden Anbieter zugewiesen ist, mit dem dieser bestimmte Tunnel-Router verbunden ist.

  • Die ITR(s) und ETR(s) sind direkt mit der Quelle bzw. dem Ziel verbunden, aber die Quelle und das Ziel können sich überall in der LISP-Site befinden.

  • Map-Requests können auf der zugrunde liegenden Routing-System-Topologie, an ein Zuordnungsdatenbanksystem oder direkt über eine Alternative Logical Topology [RFC6836] gesendet werden. Eine Map-Request wird für ein externes Ziel gesendet, wenn das Ziel nicht in der Weiterleitungstabelle gefunden wird oder mit einer Standardroute übereinstimmt.

  • Map-Replies werden auf der zugrunde liegenden Routing-System-Topologie gesendet.

Client host1.abc.example.com möchte mit Server host2.xyz.example.com kommunizieren:

  1. host1.abc.example.com möchte eine TCP-Verbindung zu host2.xyz.example.com öffnen. Es führt eine DNS-Abfrage auf host2.xyz.example.com durch. Ein A/AAAA-Datensatz wird zurückgegeben. Diese Adresse ist die Ziel-EID. Die lokal zugewiesene Adresse von host1.abc.example.com wird als Quell-EID verwendet. Ein IPv4- oder IPv6-Paket wird erstellt und als normales IP-Paket durch die LISP-Site weitergeleitet, bis es einen LISP-ITR erreicht.

  2. Der LISP-ITR muss in der Lage sein, die Ziel-EID auf einen RLOC eines der ETRs an der Ziel-Site abzubilden. Die spezifische Methode, die dafür verwendet wird, wird in diesem Beispiel nicht beschrieben. Siehe [RFC6836] oder [CONS] für mögliche Lösungen.

  3. Der ITR sendet eine LISP Map-Request. Map-Requests SOLLTEN ratenbegrenzt sein.

  4. Wenn kein alternatives Zuordnungssystem verwendet wird, wird das Map-Request-Paket über das zugrunde liegende Routing-System geroutet. Andernfalls wird das Map-Request-Paket auf einer alternativen logischen Topologie geroutet, beispielsweise dem [RFC6836]-Datenbank-Zuordnungssystem. In beiden Fällen wird es, wenn die Map-Request an einem der ETRs an der Ziel-Site ankommt, das Paket als Kontrollnachricht verarbeiten.

  5. Der ETR schaut sich die Ziel-EID der Map-Request an und gleicht sie mit den Präfixen in der konfigurierten EID-zu-RLOC-Zuordnungsdatenbank des ETR ab. Dies ist die Liste der EID-Präfixe, die der ETR für die Site unterstützt, in der er sich befindet. Wenn es keine Übereinstimmung gibt, wird die Map-Request verworfen. Andernfalls wird eine LISP Map-Reply an den ITR zurückgegeben.

  6. Der ITR empfängt die Map-Reply-Nachricht, analysiert die Nachricht (um die Formatgültigkeit zu prüfen) und speichert die Zuordnungsinformationen aus dem Paket. Diese Informationen werden im EID-zu-RLOC-Zuordnungs-Cache des ITR gespeichert. Beachten Sie, dass der Map-Cache ein On-Demand-Cache ist. Ein ITR verwaltet seinen Map-Cache auf eine Weise, die für seine Ressourcenbeschränkungen optimiert.

  7. Nachfolgende Pakete von host1.abc.example.com an host2.xyz.example.com werden vom ITR mit einem vorangestellten LISP-Header versehen, wobei der geeignete RLOC als LISP-Header-Zieladresse verwendet wird, die vom ETR gelernt wurde. Beachten Sie, dass das Paket aufgrund der Hashing-Richtlinie der Quell-Site oder der Locator-Set-Richtlinie der Ziel-Site an einen anderen ETR als den gesendet werden KANN, der die Map-Reply zurückgegeben hat.

  8. Der ETR empfängt diese Pakete direkt (da die Zieladresse eine seiner zugewiesenen IP-Adressen ist), überprüft die Gültigkeit der Adressen, entfernt den LISP-Header und leitet Pakete an den angeschlossenen Zielhost weiter.

Um die Notwendigkeit einer Zuordnungsabfrage in umgekehrter Richtung zu verschieben, KANN ein ETR einen Cache-Eintrag erstellen, der die Quell-EID (innere Header-Quell-IP-Adresse) auf den Quell-RLOC (äußere Header-Quell-IP-Adresse) in einem empfangenen LISP-Paket abbildet. Ein solcher Cache-Eintrag wird als "gesammelte" Zuordnung bezeichnet und enthält nur einen einzelnen RLOC für die betreffende EID. Vollständigere Informationen über zusätzliche RLOCs SOLLTEN durch Senden einer LISP Map-Request für diese EID verifiziert werden. Sowohl der ITR als auch der ETR können auch die Entscheidung beeinflussen, die der andere bei der Auswahl eines RLOC trifft. Siehe Abschnitt 6 für weitere Details.

Letztes Update am