8. Deployment Scenarios (Bereitstellungsszenarien)

8. Deployment Scenarios (Bereitstellungsszenarien)

Dieser Abschnitt untersucht, wie und wo ITRs und ETRs bereitgestellt werden können, und erörtert die Vor- und Nachteile verschiedener Bereitstellungsszenarien. Detailliertere Bereitstellungsempfehlungen finden Sie in [LISP-DEPLOY].

Es gibt zwei grundlegende Arten von Bereitstellungskompromissen zu berücksichtigen: zentralisiertes Caching versus verteiltes Caching und flaches (Flat), rekursives (Recursive) oder wieder-kapselndes (Re-encapsulating) Tunneling. Bei der Wahl zwischen zentralisiertem und verteiltem Caching sollte berücksichtigt werden:

• Sind Tunnel-Router ausreichend verteilt, sodass Caches über den Speicher verschiedener Router verteilt werden können? Zentralisiertes Caching bedeutet, dass ein ITR einen Cache für alle EIDs beibehält, zu denen er kapselt, und Pakete direkt zum Ziel-Locator gehen. Verteiltes Caching bedeutet, dass ein ITR die Hilfe anderer Wieder-Kapselungs-Router benötigt, da er keine Cache-Einträge für alle EIDs speichert, zu denen er kapselt, sodass Paketpfade durch Wieder-Kapselungs-Router gehen, die unterschiedliche Sätze von Cache-Einträgen halten.

• Sollte die Anzahl der administrativen "Berührungspunkte" minimiert werden, indem nur wenige Tunnel-Router ausgewählt werden (nur genug, um Redundanzanforderungen zu erfüllen)?

• Im Allgemeinen erhöht die Verwendung von mehr ITRs den Verwaltungsaufwand nicht, da Caches dynamisch aufgebaut und gespeichert werden. Andererseits erfordert die Verwendung von mehr ETRs mehr Verwaltung, da Zuordnungen von EID-Präfixen zu RLOCs explizit konfiguriert werden müssen.

Bei der Wahl zwischen flachem, rekursivem oder wieder-kapselndem Tunneling sollte berücksichtigt werden:

• Flaches Tunneling implementiert einen einzelnen Tunnel zwischen Quell- und Ziel-Site und bietet in der Regel einen besseren Einzeltunnel-Pfad zwischen Quelle und Ziel.

• Rekursives Tunneling bezieht sich darauf, dass bereits getunnelter Verkehr in einen weiteren Tunnel gekapselt wird, um VPN oder Traffic Engineering (TE) zu implementieren. Bei VPN-basiertem Tunneling hat die Site eine gewisse Kontrolle, da die Site den neuen Tunnel-Header voranstellt. Bei TE-basiertem Tunneling kann die Site Kontrolle haben, wenn die Site den neuen Tunnel-Header voranstellt, aber keine Kontrolle, wenn der Site-ISP das TE durchführt. Rekursives Tunneling führt in der Regel zu suboptimalen Pfaden, kann jedoch Verkehr in besser ressourcenversorgten Bereichen des Netzwerks lenken.

• Wieder-Kapselungstechniken stellen sicher, dass Pakete nur einen Tunnel-Header-Layer benötigen. Wenn ein Paket umgeleitet werden muss, wird es zunächst von einem ETR entkapselt und dann mit einem neuen RLOC und einem neuen Tunnel-Header wieder gekapselt.

Die nächsten Unterabschnitte untersuchen, wo Tunnel-Router im Netzwerk positioniert werden können.