Zusammenfassung

  • Beim Shuffling ersetzt der Ingress-PE in Session und Sender Template die Kundenport-Kennungen CPI durch Providerport-Kennungen PPI; der Egress-PE kehrt die Übersetzung um.
  • Eine durchgehende Sitzung sagt daher nicht, welche PIT-Version entschied, welcher interne Port geschaltet wurde oder ob die Datenebene den beabsichtigten Dienst erbrachte.

Eine stabile Sicht mit beweglichen Bezeichnern

Der Kundenrand formuliert seine Absicht in einem eigenen Namensraum: Dieser lokale Port soll mit jenem entfernten Port verbunden werden. Die Anfrage betritt ein Netz mit einer anderen Namenshoheit und verlässt es am fernen Rand wieder in der Sprache des Kunden. Aus Sicht beider CEs bleibt es eine Sitzung.

RFC 5251 nennt den Mechanismus Shuffling. Der Eingangs-PE schreibt die RSVP-TE-Objekte Session und Sender Template um. Customer Port Identifiers werden zu Provider Port Identifiers. Am Ausgang werden die PPI wieder in CPI zurückübersetzt. Die logische Sitzung bleibt erhalten, gerade weil die darunterliegenden Namen zweimal wechseln.

So können Kundennetz und Provider ihre Adressierung unabhängig halten und die interne Topologie muss nicht offengelegt werden. Der Trugschluss beginnt erst, wenn die stabile Außensicht als Nachweis einer unveränderten physischen Wirklichkeit dient. Sie bescheinigt eine Kontrollzustandsfolge, nicht jede nachgelagerte Ausführung.

Gleiche Zahl, andere Zuständigkeit

Ein CPI bezeichnet die Kundenseite eines Ports. Ein PPI bezeichnet die Providerseite. Ein VPN-PPI stellt den PE-Port im Adressraum des L1VPN-Kunden dar. Die PPI-Zuteilung liegt beim Provider; CPI- und VPN-PPI-Adressen werden in der L1VPN-Verwaltung beherrscht.

Bei unnummerierten Ports dürfen PPI und VPN-PPI der Bequemlichkeit halber denselben Portindex tragen. Die Gleichheit der Zahl vereinigt ihre Namensräume nicht. Ein Protokollsatz „Port 17“ ohne Typ, VPN-Kontext und Beobachtungsgrenze verliert genau die Information, die eine spätere Rekonstruktion braucht.

Auch Kontrollkanaladressen sind nur innerhalb eines L1VPN eindeutig. Andere L1VPNs dürfen dieselben Werte verwenden. Deshalb gehört die eindeutige Bindung des Kanals an das VPN zum Beweis. Eine Adresse allein ist keine weltweite Identität.

Die PIT-Version ist Teil der Entscheidung

Jeder Provider-Rand führt eine VPN-spezifische Port Information Table. Sie enthält CPI-PPI-Paare und für lokale Ports die VPN-PPI-Information. Provisionierung kann sie befüllen; BGP- oder OSPF-Verfahren aus RFC 5195 und RFC 5252 können Informationen zuliefern.

Für das Shuffling ist jedoch nicht nur wichtig, woher ein Eintrag stammt, sondern welcher Eintrag bei der konkreten Anfrage verwendet wurde. Der Ingress-PE wählt die PIT des L1VPN, löst den Ziel-CPI zum PPI auf und ersetzt die Werte. Am anderen Rand führt ein weiterer Tabellenzugriff die Gegenrichtung aus.

Der heutige Tabellenstand reicht für die Erklärung von gestern nicht. Eine formal gültige Zeile kann veraltet, falsch provisioniert oder dem falschen Kontext zugeordnet sein. Dann führt die Software eine syntaktisch korrekte Übersetzung zur falschen Ressource aus. RFC 5251 hält deshalb den Schutz von Management und Konfiguration für wesentlich und empfiehlt, eine Datenebenenprüfung gegen versehentliche Fehlkonfiguration zu erwägen.

Das ist eine saubere Beweisgrenze. Signalisierung kann ihre eigene Verarbeitung nachweisen. Ein CE-zu-CE-Test beobachtet eine Wirkung der resultierenden Verbindung. Keiner dieser Belege darf für die andere Ebene sprechen.

Verborgene Topologie bleibt reale Topologie

Innerhalb des Providernetzes tragen die Nachrichten PPI. Wenn Shuffling eingesetzt wird, muss die Randübersetzung für alle betroffenen RSVP-TE-Nachrichten gelten. Eine nur teilweise Umsetzung würde widersprüchliche Zustände unter derselben sichtbaren Sitzung erzeugen.

Dem Kunden erscheint ein LSP mit einer virtuellen Verbindung zwischen den PEs. Der Provider sieht den PE-zu-PE-Abschnitt im Detail. Er darf Topologieinformationen filtern und Record-Route- oder Notification-Objekte an der Grenze entfernen oder bearbeiten. Der Schutz interner Architektur ist eine legitime Dienstgrenze.

Eine bereinigte Kundensicht erlaubt aber keinen Rückschluss auf einen einfachen Pfad. Eine Sitzung bedeutet nicht einen physischen Hop, eine Faser, eine Wellenlänge oder eine unveränderliche Route. Der interne Nachweis darf geschützt sein; fehlen darf er nicht.

Zudem erlaubt RFC 5251 stitched und nested Betriebsweisen. Eine PE-zu-PE-Sitzung, ein bestehender LSP oder eine Forwarding Adjacency kann nach RFC 5150 oder RFC 4206 mit der Kundenanfrage verbunden werden. Zwei äußerlich ähnliche Dienste können daher völlig verschiedene interne Belegketten besitzen. Der Modus gehört in den Vorgang.

Annahme ist noch keine Kreuzschaltung

Der Quell-CE wählt ein bekanntes Ziel. Providerregeln begrenzen erlaubte Porttopologien. Der PE übersetzt Kennungen und berechnet den internen Weg. Der Ziel-CE nimmt an oder lehnt ab. Jeder Schritt ist eine Entscheidung mit begrenzter Aussagekraft.

Path und Resv sind Belege der Kontrollebene. Ressourcenreservierung, Label- oder Wellenlängenprogrammierung, Schutzstatus, physische Kontinuität und übertragener Kundenverkehr liegen danach. Selbst ein erfolgreicher Durchgangstest beweist nur das tatsächlich gesendete und empfangene Muster; SLA-Leistung und Anwendungserfolg benötigen eigene Messungen.

Auch ein vom Kunden geliefertes Explicit Route Object überträgt nicht die Hoheit über jeden Provider-Hop. Der PE kann es ablehnen. Bei einer erlaubten losen Form berechnet und ergänzt er weiterhin den internen Pfad. Kundenabsicht beschränkt die Leistung, autorisiert aber nicht jede technische Umsetzung.

Einen später erklärbaren Beleg bauen

Die Kette beginnt mit L1VPN, Kontrollkanal, ursprünglichem Quell- und Ziel-CPI sowie der Anfrage. Danach folgen exakte PIT-Generation, Zeilenherkunft, aufgelöste PPI und die Werte vor und nach der Umschreibung. Am Ausgang müssen Rückwärtszugriff, wiederhergestellte CPI und Zielantwort erhalten bleiben.

RSVP-Zustand, Ressourcenprogrammierung, physische Schaltung, Datenebenentest und beobachteter Dienst bilden weitere Stufen. Ein normalisiertes Feld „session up“ kann sie nicht ersetzen. Sobald sich Provisionierung ändert, wäre sonst die Zuordnung einer laufenden oder vergangenen Sitzung nicht mehr erklärbar.

Lu Hengs Disziplin der Realitätsebenen führt zu einer praktischen Regel: Ein Name im Kundenraum ist nicht dieselbe Tatsache wie ein Name im Providerraum. Eine erfolgreiche Übersetzung ist keine beobachtete physische Verbindung. Eine ungeteilte Sitzung ist noch kein ungeteilter Dienst. Ein laufendes System bleibt rechenschaftsfähig, wenn jede Grenze festhält, was sie umgeformt und was sie wirklich gesehen hat.

Quellen