computerwoche.de

Archiv

Deutsche Flugsicherung: Wer nutzt welchen Dienst im LAN?

Kosten des IP-Verkehrs werden sichtbar

25.01.2002
OFFENBACH (sra) - Im Weitverkehrsnetz, das die Standorte der Deutschen Flugsicherung (DFS) verbindet, wächst der Anteil an IP-Verkehr. Diese Entwicklung bewog die DFS dazu, ein IP-taugliches Abrechnungssystem anzuschaffen. Ein solches System ordnet die Kosten im LAN einzelnen Anwendungen zu.

Die in Offenbach ansässige DFS ist verantwortlich für den reibungslosen Ablauf des bundesweiten Flugverkehrs. Ihre Aufgaben umfassen vor allem die Verkehrslenkung sowie die Entgegennahme, Bearbeitung und Weiterleitung von Flugplänen. Außerdem plant, errichtet und wartet die Flugsicherung alle für diese Zwecke notwendigen technischen Einrichtungen. Ihre Standorte verbindet sie über ein Weitverkehrsnetz, das auf Nortel-Networks-Komponenten basiert.

Über dieses Netz transportiert die DFS Flugpläne und Radardaten - aus historischen Gründen noch vielfach via X.25. Ursprünglich wurde es aufgebaut, um gegenüber einem ähnlichen Angebot von alternativen Carriern Geld zu sparen und eine höhere Verfügbarkeit zu erzielen. Inzwischen ist das Netz deutlich gewachsen. Die DFS betreibt darin heute Sprach-Daten-Integration und verwendet neben X.25 weitere Protokolle wie Frame Relay, QSIG und künftig auch ATM. Einen immer größeren Anteil im WAN erobern IP-Dienste.

Standardprojekt mit kleinen AnpassungenFür die alten X.25- und Frame-Relay-Services nutzt die DFS schon seit längerem ein "Data Billing System" von Nexus. Dieses System hatte den Zweck, die Kosten des Netzverkehrs transparent zu machen - sowohl für die Netzverantwortlichen selbst als auch für die Leute, die den Dienst anwenden. Es sollte klären, welche Daten überhaupt übertragen werden und ob sich das Netz rentiert. Die DFS berechnet lediglich einen Einheitspreis, um intern Vergleichbarkeit herzustellen. Rechnungen wurden damit nicht erstellt. Dieses System hatte jedoch einen Haken: Es ließ sich nicht auf die Schnelle für IP anpassen.

Daher hielt die DFS Ausschau nach Alternativen. "Da gab es noch nicht besonders viel", berichtet Armin Biegel, Leiter Produkt-Management Basisdienste bei der DFS in Offenbach. "IP-Accounting war zwar überall ein Schlagwort, funktionstüchtige Lösungen hingegen Mangelware." In Gesprächen sondierte der Spezialist die Möglichkeiten der Hersteller, eine solche Lösung nach seinen Vorgaben zu realisieren. Übrig blieb eine kleine Auswahl, die Biegel dann zu einer Teststellung aufrief. Darunter war auch die Uni-X Software AG aus Osnabrück mit der Lösung "Open Informer".

Zu den Vorgaben der DFS gehörte, dass die Sammlung der Daten über Probes (spezielle Sonden an den Netzzugängen) erfolgen sollte. "Für Wartung und Troubleshooting hatten wir bereits Probes im Einsatz. Es wäre unökonomisch gewesen, sie nicht einzubeziehen", erläutert Biegel. Bei Uni-X existierten bereits Softwaremodule für die Kommunikation mit Probes. Im Wesentlichen habe es sich daher um ein Standardprojekt mit kleinen Anpassungen gehandelt, urteilt Biegel. Insgesamt sei er sehr zufrieden mit dem Produkt.

Während der Testphase trat eine kleine, unvorhergesehene Schwierigkeit auf: Die Probes des Anbieters Netscout arbeiteten anfangs nicht richtig mit dem Open Informer zusammen, so dass es zunächst nicht möglich war, Daten an das weiterverarbeitende System zu liefern. Entwickler von Uni-X fanden heraus, dass die Schwierigkeit bei der Abfrage der Schnittstellen lag.

In die Kategorie "kleine Herausforderungen" fällt auch das Ausfiltern doppelt übertragener Pakete. Da die DFS ein hohes Maß an Verfügbarkeit sicherstellen muss, sind die Leitungen zu den größeren Standorten redundant ausgelegt. Trotzdem dürfen doppelt übertragene Pakete nicht zweimal abgerechnet werden.

LAN-Kosten einem Dienst zugeordnetNach Angaben des Herstellers ist es einfach, die Pakete zu vergleichen und Duplikate herauszufiltern, wenn die Datensätze sehr genau beschrieben sind. Sind dagegen nur eine Quell- und eine Zieladresse sowie ein paar Byte Länge bekannt, so sind zusätzliche Redundanzfilter erforderlich, die das Netzdesign berücksichtigen. Dass das Ausfiltern redundanter Pakete funktioniert, bestätigt auch der Anwender. Weichen die gemessenen Datenmengen auf den redundanten Pfaden voneinander ab, so zählt der Open Informer normalerweise den höheren Wert. Das wollte Biegel jedoch nicht zulassen - mit der Begründung, innerhalb des WAN könnten ja Daten verworfen werden. In diesem Fall kämen am Ende der Leitung weniger Daten an, als abgeschickt wurden, und der jeweilige Kunde müsse mehr bezahlen, als wirklich übertragen worden sei. Auf Wunsch des Anwenders nahm die Uni-X Software AG die entsprechende Änderung vor, so dass nun der minimale Wert in die Abrechnung eingeht.

Die bei weitem größte Herausforderung stellte jedoch die anwendungsabhängige Abrechnung im LAN dar. Im lokalen Netz sollten die Kosten nicht nur dem Endnutzer zugewiesen werden, der sie verursacht hat, sondern auch einem Dienst. "Wir wollten wissen, ob das E-Mail-, Internet- oder SAP-Verkehr war", skizziert Biegel die Beweggründe. "Das ging nur über sehr umfangreiche Regelwerke." Der Grund: Der Open Informer öffnet die einzelnen Datenpakete nicht. Dann aber liefern die Probes prinzipiell nur die IP-Adressen von Quelle und Ziel, die Zeitstempel und Angaben, wie viel Bytes übertragen worden sind.

Den Bezug zu einem Dienst definieren nun Regeln (Filter): Falls Daten zu einer IP-Adresse fließen, die einem SAP-Server gehört, handelt es sich beispielsweise um SAP-Verkehr. Wenn sie von dort kommen, war es die Antwort des SAP-Servers. "Die Regelwerke waren der Hauptgrund, warum wir uns für den Open Informer entschieden haben. Dessen Regeln waren so, wie wir sie brauchten", resümiert Biegel.