Zusammenfassung

  • PROPOSE und PROPOSE ACK identifizierten und prüften eine Dedicated-VC zwischen zwei Nachbarn; erst OFFER und READY ordneten ihr einen durch Quell- und Zieladresse definierten IPv4-Fluss zu.
  • Diese Nachbarschaftszuordnung konnte abgelehnt werden und verfiel ohne laufende Erneuerung. Sie bewies weder Zustellung über die gesamte Route noch dauerhafte Kapazität oder QoS.

Die erste Quittung war zu schmal

Der vorgelagerte Router wählte zunächst eine Dedicated-VC. Darüber schickte er PROPOSE mit einer VCID und der Ziel-IP-Adresse des nachgelagerten Nachbarn. Dessen PROPOSE ACK kam über die Default-VC zurück, die zugleich das gewöhnliche IP-Weiterleiten von Hop zu Hop ermöglichte. Beide Seiten konnten nun dieselbe benachbarte Verbindung benennen; die Verbindung und der Nachbar waren überprüft. Ein bestimmter Paketfluss war damit noch nicht zugeteilt.

Erst das nachfolgende OFFER über die Default-VC nannte VCID, Flow-ID und ein Intervall für spätere READY-Meldungen. Mit READY, ebenfalls über die Default-VC, zeigte der Nachbar an, dass er diesen Fluss auf der Dedicated-VC empfangen konnte. Eine ausgesandte Offerte ist nicht die empfangene Annahme. Und die erste Quittung darf nicht als zweite ausgegeben werden. Der RFC 2129 ließ diese Aushandlung zwischen Nachbarn stattfinden: Im Beispiel mit drei Routern lief der Vorgang auf dem nächsten Abschnitt unabhängig erneut ab.

Das Dokument war Informational und legte keinen Internetstandard fest. FANP verwaltete die Abbildung von IP-Paketflüssen auf eine verbindungsorientierte Datenlink-Verbindung. Für normale Hop-by-Hop-Verarbeitung blieb die Default-VC erhalten. Bei einer passenden Zuordnung konnte ein Cell Switch Router Zellen anhand der Verbindungskennungen weiterleiten, ohne an dieser Stelle jeden IP-Header erneut zu bearbeiten. Diese lokale Abkürzung war weder ein universeller Pfad noch eine Instanz, die die Weiterleitung aller weiteren Router autorisierte.

Der Preis der Bereitschaft

Ein Auslöser wurde nach lokaler Regel gewählt, im Text beispielhaft anhand von TCP/UDP-Ports für langlebige oder umfangreiche Sitzungen. Der Router konnte vorbereitete VCs aus einem Vorrat nehmen: kurze Aktivierungszeit gegen belegte, gegebenenfalls ungenutzte Ressourcen. Oder er richtete die Verbindung bei Bedarf per ATM-Signalisierung ein: weniger Vorhaltung gegen Einrichtungszeit. Das Dokument stellte die Abwägung jedem Knoten frei. Aus dem Entwurf folgt keine gemessene Wirtschaftlichkeit einer konkreten Installation.

Auch die Kennungen hatten enge Bedeutungen. Die definierte Flow-ID enthielt nur Quell- und Ziel-IPv4-Adresse und war ausdrücklich nicht das Flow Label von IPv6. Die VCID bezeichnete die Verbindung zwischen Nachbarn auch bei unterschiedlichen lokalen VPI/VCI-Werten. Keines der Felder beglaubigte den Absender. Aggregierte Flüsse, Multicast, IP-QoS-Signalisierung und IPv6 gehörten zu den künftigen Erweiterungen, nicht zum nachgewiesenen Umfang dieses Entwurfs.

Warum die Zuordnung wieder verschwindet

Ein Nachbar konnte PROPOSE aus politischen Gründen, wegen eines unbekannten VCID-Typs oder mangels Ressourcen zurückweisen. Auch OFFER konnte an unbekannten Kennungen, Flussregeln, nicht akzeptierten Erneuerungsintervallen oder fehlenden Ressourcen scheitern. Blieb eine Antwort aus, wurde wiederholt; nach den im RFC empfohlenen fünf erfolglosen Wiederholungen sollte die ausgewählte VC freigegeben werden. Schweigen war keine Zustimmung.

Während Pakete über die Dedicated-VC eingingen, sollte der nachgelagerte Knoten regelmäßig READY schicken. Ohne eingehende Pakete unterließ er dies. Der vorgelagerte Knoten entfernte die Flow-ID/VCID-Zuordnung nach ausbleibender Erneuerung; der nachgelagerte bereinigte seine Zuordnung nach längerer Paketstille, auch bei einem stillen Ausfall des Gegenübers. Zwei, sechs und zwanzig Minuten waren empfohlene Beispielintervalle mit bestimmter Reihenfolge, kein allgemeines Leistungsversprechen. Ein explizites REMOVE/REMOVE ACK oder das Freigeben der ATM-Verbindung ergänzte die Bereinigung je nach VC-Art.

Historisch interessant ist die Abstufung des Nachweises. Ein Trigger, eine ausgewählte VC, ein ACK, ein READY und eine spätere Erneuerung belegen nicht denselben Zustand. Keiner davon belegt authentische Herkunft, Übereinstimmung an allen Hops, Zustellung, anhaltende Kapazität, QoS oder einen finanziellen Nutzen. RFC 2098 lieferte den benachbarten Architekturkontext für den Bypass; RFC 2129 zeigte die laufende Abstimmung, ohne die eine schnelle lokale Abkürzung ihren Sinn verlieren kann.

Quellen