Zusammenfassung

  • RFC 3186 ersetzte am Eingang ein oder zwei PPP/POS-Headerbytes durch eine MAPOS-Zieladresse und stellte sie am Ausgang wieder her. So entstand ohne zusätzlichen Header die Ansicht einer Punkt-zu-Punkt-Leitung.
  • Der reale Dienst erforderte zwei Portzustände, ein freies Adresspaar, stabile Weiterleitung in beiden Richtungen und Pfadisolation. Die OAM-Datenbank war Beschreibung, nicht Datenebene.

Das Dokument erschien im Dezember 2001 als Informational RFC. Die IESG Note betonte, dass es weder aus einer IETF-Arbeitsgruppe stammte noch Standards Track war und nicht zwingend dieselbe breite Prüfung erhalten hatte. Referenzaufbau und Messung sind begrenzte historische Evidenz.

Technisch nutzte der Entwurf ähnliche Rahmenformate. PPP over SONET/SDH begann mit festen Werten; MAPOS konnte dort sein internes Ziel tragen. Der Eingangsswitch schrieb die Adresse des entfernten Ports ein, das Netz leitete danach weiter, der Ausgangsswitch stellte die PPP-Werte wieder her.

Für das CPE erschien kein zusätzlicher Tunnelheader. Dafür lag der Zustand im Netz: Rewrite-Ziel, Portmodus, C2, Route, Portzuordnung und Isolationsregel. Transparenz entfernte Komplexität aus der Kundenschnittstelle, nicht aus dem Betrieb.

Der Moduswechsel bestand aus Einzelschritten. NSP und SSP wurden am Kundenport abgeschaltet, Broadcast und Multicast gesperrt, C2 passend zum Scrambling gesetzt und Header-Rewriting aktiviert. Die Rückkehr zu MAPOS kehrte die Reihenfolge um. Ein Modusfeld konnte Teilerfolge nicht erklären.

Zur Einrichtung wählte der Betreiber ein unbenutztes MAPOS-Adresspaar und konfigurierte beide Ränder. Erst nach stabilen Routen und stabilem Forwarding in beiden Richtungen galt der Pfad als hergestellt. Bis dahin sollte der Kundenlink down bleiben; anschließend konnten LCP-Nachrichten transparent passieren.

Das Adresspaar bezeichnete den verwalteten Pfad. Es bewies weder den korrekten Modus beider Seiten noch bidirektionale Erreichbarkeit oder Zustellung.

Die empfohlene Pfaddatenbank sollte Verwaltung erleichtern und Duplikate verhindern. Ihr Beispiel enthielt einen Status „Up and running“. Zugleich war sie ausdrücklich nicht an der Frame-Weiterleitung beteiligt.

Ein grüner Eintrag war somit eine Betreiberbehauptung. SSP, Ports und Rewriting erzeugten den Laufzustand. Inventar und Datenebene konnten zeitlich auseinanderlaufen, ohne dass eines das andere ersetzte.

Auch das Entfernen bestand aus getrennten Akten: Kundenports abschalten, Datenbank gegebenenfalls aktualisieren, native Defaults wiederherstellen. Frames nach Abschaltung des Zielports wurden still verworfen. Der Absender erhielt keinen Ursachenbeleg.

Fehler waren asymmetrisch sichtbar. Ein optischer Bruch am nahen Rand erzeugte lokale SONET/SDH-Alarme. Der ferne physische Link blieb up, weil der optische Weg im MAPOS-Netz endete. Erst nach LCP-Echo-Ablauf erschien „link up, line protocol down“.

Der Timeout belegte fehlende Antwort im Zeitfenster. Er lokalisierte den Bruch nicht und bewies weder beidseitigen Ausfall noch Anwendungsschaden. SSP konnte intern auf Topologieänderung reagieren, während der Kunde nur das Ende-zu-Ende-Symptom sah.

Eine private Linkansicht bedeutete keine private Kapazität. MAPOS hatte keine QoS-Funktion auf Protokollebene, POS keine Flusskontrolle. Das RFC hielt Durchsatzgarantien für schwierig und forderte ausreichende Zwischenkapazität sowie Portfairness bei Überbuchung.

Die Latenzmessung hatte enge Bedingungen: benannte Geräte, unidirektionale OC12c-Last von 30 Prozent, feste Parameter und 25 Läufe zu 150 Sekunden je Framegröße. Der getestete Switch war dort schneller als der Vergleichsrouter. Das ist keine Aussage über alle Lasten, Hersteller oder Anwendungen.

Im Sicherheitsabschnitt galt direkter CPE-Zugriff auf das Innere als schwierig. Dennoch waren Pfadisolation und Vermeidung von Duplikaten zentral. Mischbetrieb aus nativem MAPOS und PPP-Tunnel wurde abgelehnt, solange nicht alle Switches Isolation beherrschten.

MAPOS-Frames hatten kein Quelladressfeld. Gerade im Mischbetrieb erschwerte das die Zuordnung. Unsichtbarkeit des Netzes für den Kunden war daher kein Beweis für korrekte Trennung im Netz.

RFC 3186 zeigt, wie eine nützliche Abstraktion Beweismacht verschiebt. Serviceauftrag, Adresspaar, Ports, Modusschritte, Richtungs-Konvergenz, Datenbankversion, Isolation, Alarme, LCP Echo und Framebeobachtung müssen getrennt bleiben. Die transparente Leitung ist eine Darstellung, nicht die ganze Wirklichkeit.