Zusammenfassung

  • RFC 3474 schlug eine über die Lebensdauer eines ASON-Calls konstante CALL_ID vor und unterschied eine betreiberspezifische von einer global eindeutigen Form.
  • Die Kennung bezeichnete die Beziehung; Connections, RSVP-Zustand, lokale Labels, geschaltete Ressourcen, Signal, Verkehr und Dienst blieben getrennt nachzuweisende Tatsachen.

Eine stabile Nummer kann ein Ereignis überdauern, ohne dessen technische Wirkung zu überdauern. RFC 3474 machte diese Differenz im März 2003 für ASON und GMPLS RSVP-TE sichtbar. Das Dokument erschien als Informational, nicht als Internet Standard. Es hielt einen Vorschlag für soft permanent connections, Call/Connection-Trennung, Wiederanlauf und zusätzliche Fehler fest, aber keine allgemeine Einführung.

Der Call war eine Beziehung zwischen Endpunkten und gehörte in die Zuständigkeit eines Call Controllers. Eine Connection war die ressourcentragende Realisierung und gehörte zum Connection Controller. Unter derselben Beziehung konnten Pfade entstehen, wechseln oder verschwinden. Verwaltungsobjekt und transportierende Infrastruktur waren deshalb nicht dasselbe.

CALL_ID stellte die Referenz her. Die globale Form setzte sich aus ISO-Ländercode, ITU-Carrier-Code, einem organisationskontrollierten Access-Point-Code, der Adresse des Quell-LSR und einer lokalen Kennung zusammen. Diese 64-Bit-Kennung sollte während der gesamten Lebensdauer des Calls unverändert bleiben.

Die Kombination mehrerer Namensräume klang verbindlich. Sie stärkte aber nur die Unterscheidbarkeit. CALL_ID reservierte keine Wellenlänge, programmierte keinen Cross-Connect, erzeugte kein optisches Signal und lieferte keinen Verkehr. War die Quelladresse nur im Betreiberbereich gültig, folgte aus der Form auch nicht automatisch weltweite Eindeutigkeit.

Die Vergabe hatte eine eigene Autoritätsgrenze. Ein anfänglicher Nutzer durfte den Wert null senden. Der erste Netzknoten vergab dann eine Kennung oder prüfte die vorhandene Nicht-Null-Kennung. Transitknoten sollten sie unverändert weitergeben, selbst wenn sie die ASON-Erweiterung nicht verstanden. Path, Resv, PathTear, PathErr und Notify konnten dieselbe Referenz tragen. Gleiche Referenz bedeutete jedoch nicht gleichen Connection-Zustand.

Im grundlegenden Trennmodell besaß ein Call normalerweise mindestens eine Connection. Während einer Break-before-make-Wiederherstellung konnte die Zahl vorübergehend null sein: Der alte Pfad war entfernt, der neue noch nicht aufgebaut. Call und CALL_ID blieben bestehen. Eine Betriebsansicht, die den vorhandenen Call als aktive Leitung wertete, würde gerade diese Lücke verbergen.

Die optionale vollständige Trennung ging weiter. CALL_OPS erlaubte, einen Call ohne gleichzeitige Connection einzurichten oder abzugleichen. Auch im stabilen Zustand waren null, eine oder mehrere Connections möglich. Null war kein Widerspruch, sondern Ausdruck unterschiedlicher Lebenszyklen von Beziehung und Konnektivität.

SPC_LABEL zeigte dieselbe Grenze an einer anderen Stelle. Bei einer soft permanent connection verband das Objekt einen dauerhaft provisionierten Eingangsabschnitt mit einem geschalteten Abschnitt. Wie diese Zuordnung entstand, blieb lokaler, außerhalb des Dokuments liegender Politik überlassen. Über Nicht-GMPLS-Teilnetze hinweg waren Labels lokal für den Steuerknoten und konnten manuell provisioniert oder vorher entdeckt werden. Eine gültige lokale Zuordnung belegte keinen durchgehenden physischen Pfad.

Nach einem Neustart konnten persistente Speicherung, Nachbarableitung oder Managementanweisung Informationen liefern. Eine wiedergefundene CALL_ID belegte die Erinnerung an die Beziehung. Sie belegte weder Übereinstimmung des Nachbarn noch abgeschlossene RSVP-Signalisierung, Hardwareprogrammierung, Signal oder Dienst.

Auch Notify vereinte die Ebenen nicht. Eine Nachricht konnte Sitzungen mehrerer Calls enthalten. Nachrichtenhülle, Call-Identität und Zustand jeder Connection mussten korreliert werden, ohne als identischer Sachverhalt zu gelten.

Die spätere Entwicklung darf nicht zurückprojiziert werden. RFC 4139 beschrieb ASON-Anwendbarkeit und Anforderungen. RFC 4974 definierte 2007 auf dem Standards Track vollständigere Call-Verfahren und stellte klar, dass ein Call selbst keine Verkehrskonnektivität bereitstellt; er kann null, eine oder mehrere Connections haben. RFC 6004 ergänzte UNI-Attribute. Das zeigt Verfeinerung, nicht die Implementierung des Informational-Vorschlags von 2003.

Mit Heng Lus Trennung von Symbol, Entscheidung und Betriebswirklichkeit wird die Prüfung einfach. CALL_ID ist ein Koordinationssymbol. Die Zulassung durch den Call Controller und der Aufbau durch den Connection Controller sind getrennte Entscheidungen. Programmierte Ressourcen, physisches Signal, bidirektionaler Verkehr und Anwendungsergebnis sind Beobachtungen. Ein gemeinsamer Schlüssel verbindet sie, ersetzt aber keinen dieser Belege.

Eine belastbare Historie speichert daher Vergabestelle, Form, Eindeutigkeitsbereich, Quelladresskontext sowie Beginn und Ende des Calls. Jede Connection erhält eine eigene Identität, Zuordnungszeit, RSVP-Nachrichten, Labelherkunft, Ressourcenschaltung und Auflösung. Erst danach werden Signal-, Verkehrs- und Dienstmessungen angefügt. So bleibt eine Beziehung erkennbar, ohne eine nicht belegte Leitung zu erfinden.

Quellen