Zusammenfassung

  • Nach Empfang und Verarbeitung eines Call Release musste RFC 3475 die Freigabe aller zugeordneten Connections auslösen.
  • Jeder Zweig behielt Label Withdraw und Label Release; die Call-Bestätigung belegte daher weder atomaren Abschluss noch physische Rückgabe oder Dienstende.

Ein Abschlussbefehl kann mehrere offene Arbeiten erzeugen. RFC 3475 machte das im März 2003 für ASON sichtbar.

Das Dokument war Informational, kein Internet Standard. Es dokumentierte IANA-Codepunkte für CR-LDP-Erweiterungen der ITU-T-ASON-Arbeit und verwies die Nutzungsregeln an ITU-T-Dokumente. Es belegte einen Vorschlag, keine allgemeine Einführung.

ASON trennte den Call als Beziehung von den ressourcentragenden Connections. Ein Call konnte mehrere Connections besitzen. Call Setup und Call Release wirkten auf das obere Objekt; Labelverfahren auf jede Realisierung.

Call Release führte Source ID, Destination ID und CALL_ID. Jede Netzinstanz durfte damit einen bestehenden Call beenden. Eine Notification mit Statuscode bestätigte die Freigabe dem Initiator. Dieser Beleg blieb jedoch auf Call-Ebene.

Die Verarbeitung musste die Freigabe sämtlicher zugeordneter Connections auslösen. Jede folgte den normalen CR-LDP-Verfahren Label Release und Label Withdraw. Aus einer Entscheidung wurden mehrere Peer-, FEC- und Labelübergänge.

RFC 3036 beschreibt ihre Reihenfolge. Ein nachgelagerter LSR zog mit Label Withdraw eine Zuordnung zurück; der Empfänger antwortete mit Label Release. Auch ein vorgelagerter LSR gab eine nicht mehr benötigte Zuordnung frei. Kein solcher Beleg sagte global, dass alle Zweige verschwunden waren.

Drei Connections konnten gleichzeitig abgeschlossen, wartend und noch aktiv sein. Die Pflicht, alle freizugeben, schuf keine atomare Fertigstellung. Call-Notification und vollständiges Zweigprotokoll beantworteten verschiedene Fragen.

Darum musste die Zuordnungsliste zum Freigabezeitpunkt eingefroren werden. Eine später leere Liste verriet weder ursprüngliche Zahl noch Reihenfolge, Wiederholung oder das vorzeitige Verschwinden aus dem Inventar vor Hardwarebereinigung.

CALL_ID korrelierte den Fächer, bewies aber keine Vollendung. Es bestätigte weder jedes Withdraw, gelöschte Labels, zurückgegebene Cross-Connect-Kapazität noch Signal-, Verkehrs-, Dienst- oder Abrechnungsende.

Bei soft permanent connections konnten dauerhaft eingerichtete Nutzer-Netz-Segmente bestehen bleiben, während das gesteuerte Netzsegment abgebaut wurde. Eine freigegebene Connection bedeutete nicht, dass die gesamte Infrastruktur entfernt war.

Crankback zeigte dieselbe Evidenzgrenze beim Aufbau. Eine Notification mit ER-HOP lokalisierte Ressourcenmangel und erlaubte Neuberechnung. Der Ort der Sperre belegte nicht, dass die Alternative Kapazität hatte oder der nächste Versuch gelang.

Spätere Dokumente wie RFC 4974 dürfen nicht rückwirkend Status oder Semantik von RFC 3475 verändern. Sie beweisen auch keinen konkreten Betrieb.

In Heng Lus Realitätsebenen ist Call Release eine Anweisung, Verarbeitung eine Entscheidung, jeder Labelaustausch ein begrenzter Beleg und Zustandslöschung, Hardware, Signal, Verkehr und Dienst sind getrennte Beobachtungen. Ein verantwortliches System speichert den Connection-Schnappschuss und schließt jeden Zweig einzeln, bevor es den Call als beendet meldet.

Quellen