-
Feld der Erfindung
-
Die
Erfindung bezieht sich auf die Kommunikation zwischen Netzelementen
eines Telekommunikationsnetzes und einer Applikations-Plattform,
insbesondere in IP-Netzen.
-
Hintergrund
der Erfindung
-
Heute
entwickeln sich Telekommunikationsnetze und insbesondere IP-Netze
(IP: Internet Protocol) in Richtung auf mehr Typen von Netzelementen,
mehr Funktionalität,
mehr Protokolle, mehr Dienstunterstützung, usw. Um es Applikationen,
die Dienste implementieren, jedoch zu ermöglichen, diese Funktionen zu
nutzen, werden Mechanismen benötigt,
um Informationen über
Netzereignisse von Netzelementen zur Applikations-Plattform zu senden.
-
Da
Netzelemente intelligenter werden und mehr Funktionen unterstützen, benötigen Applikationen Mechanismen,
um mit diesen Netzelementen zu interagieren: Senden von Befehlen,
z.B. zum Aufbau von Verbindungen, zur Steuerung der Wegesuche und
NAT-Tabellen (NAT: Network Address Translation), usw., und Empfang
von Benachrichtigungen, wenn bestimmte Ereignisse auftreten, z.B.
Informationen über
die Präsenz und
den Ort von Teilnehmern, wenn ein Anwender eine Sitzung startet.
Viele dieser Funktionen sind als solche bereits über vorhandene Protokolle und
Netzelement-Schnittstellen verfügbar.
Obwohl diese Protokolle selbst bis zu einem gewissen Grad standardisiert
sind, gibt es jedoch keine Möglichkeit,
zu wissen, ob ein gegebenes Netzelement eine gegebene Benachrichtigung
oder einen gegebenen Befehl unterstützt, welche Version/Variante
es unterstützt,
usw., es sei denn, man sieht in den Benutzerhandbüchern der
Geräte
nach.
-
In
US 6,219,703 wird der herkömmliche
Zusammenhang zwischen einem Netzwerkmanager und einem verwalteten
Gerät beschrieben.
Das verwaltete Gerät
speichert eine Geräte-MIB
(Management Information Base, Management-Informations-Basis) und
eine Management-Struktur-MIB. Der Manager erkennt das Vorhandensein
des Gerätes
und lädt
die Management-Struktur-MIB, wenn das Gerät unbekannt ist. Aus der Management-Struktur-MIB
konstruiert und kompiliert er eine MIB, die der Geräte-MIB entspricht,
und lädt
sie in seinen Speicher.
-
Der
Konferenzbeitrag "Applying
Network Management Standards to System Management; the case for
the Common Agent" von
M. Sylor et al., Systems Management 1993, Proc. IEEE, Seite 110–117, beschreibt die
verschiedenen aktuellen Standards zum Netzwerk- und Systemmanagement und schlägt einen
allgemeinen Agenten vor, um sie alle in einem Agenten zu behandeln.
-
Für Applikations-Plattformen,
die auf heterogenen Netzen laufen (d.h. mehrere Arten von Netzelementen
von verschiedenen Herstellern), hat dies zur Folge, dass die Konfiguration
der Applikations-Plattform, so dass sie die korrekte Benachrichtigungs-
und Befehls-Variante für
jedes Netzelement benutzt, eine umfangreiche Aufgabe mit beträchtlichen
Betriebskosten ist.
-
Das
Problem ist, dass zurzeit ein Mechanismus fehlt, mit dem Applikations-Plattformen
herausfinden können,
welche Funktionen, Protokolle, Benachrichtigungen und Befehle ein
Netzelement an seinen Schnittstellen anbietet.
-
Zusammenfassung
der Erfindung
-
Es
ist daher eine Aufgabe der vorliegenden Erfindung, ein Netzelement
und eine damit verbundene Management-Informations- Basis bereitzustellen,
die von einer Applikation aktiv auf ihre Fähigkeiten untersucht werden
kann.
-
Diese
und weitere Aufgaben, die weiter unten deutlich werden, werden durch
ein Netzelement und eine damit verbundene Management-Informations-Basis
erfüllt,
welche die Schnittstelle zu Triggern und Handles eines Netzelementes
beschreibt. Eine Management-Informations-Basis ist eine Datenbank,
die verwaltete Objekte enthält,
die Variablen und Parameter beschreiben, auf die ein Netzwerkmanagement-System
zugreifen kann, um das Netzelement zu steuern und zu überwachen.
Diese Datenbank speichert zusätzliche
verwaltete Objekte, welche die Trigger und Handles beschreiben,
die vom Netzelement unterstützt
werden. Die Trigger sind Benachrichtigungen, die Informationen enthalten,
die bei Auftreten vordefinierter Ereignisse vom Netzelement zu einer
Applikation zu senden sind, und Handles sind Befehle, die von einer
Applikation zu senden sind, welche die Ausführung vordefinierter Aktionen
in dem Netzelement anfordert.
-
Das
Vorhandensein dieser zusätzlichen
Objekte erlaubt es einer Applikations-Plattform, die von Netzelementen
unterstützten
Schnittstellen automatisch zu erkennen und anzupassen. Dies wird
immer wichtiger, da Netze immer komplexer und unterschiedlicher
werden. Diese Selbstbeobachtung ist nicht von speziellen Softwaretechnologien
abhängig,
die in der Applikations-Plattform oder im Netzelement verwendet
werden. Es kann das SNMP-Protokoll verwendet werden, das heute von
der Mehrzahl der Netzelemente unterstützt wird, um ein Netzwerkmanagement
zu ermöglichen.
-
Ein
Trigger ist eine vom Netzelement zur Dienstlogik gesendete Information,
während
ein Handle ein von der Dienstlogik zu einem Netzelement gesendeter
Befehl ist.
-
Eine
weitere Aufgabe der vorliegenden Erfindung ist die Bereitstellung
einer Applikation und eines zugehörigen Softwaremoduls, welches
die Abfrage der Schnittstelle eines Netzelementes ermöglicht.
-
Diese
Ziele werden durch ein Softwaremodul erreicht, das Teil einer Applikations-Plattform
ist. Das Softwaremodul ist so angepasst, dass es eine Schnittstelle
eines Netzelementes abfragt, um herauszufinden, welche Trigger und
Handles das Netzelement unterstützt.
Das Modul sendet Anforderungen an das Netzelement und speichert
Informationen, die es vom Netzelement zurück empfangen hat, in einem
Datenmodell.
-
Gemäß Aspekten
der vorliegenden Erfindung wird dann eine Management-Informations-Basis
bereitgestellt, wie in Anspruch 1 spezifiziert, ein Netzelement,
wie in den Ansprüchen
2 und 3 spezifiziert, ein Softwaremodul, wie in den Ansprüchen 4 bis
6 spezifiziert, eine Applikation, wie in Anspruch 7 spezifiziert
und ein Verfahren, wie in den Ansprüchen 8 bis 10 spezifiziert.
-
Kurzbeschreibung
der Zeichnungen
-
Im
Folgenden wird eine bevorzugte Ausführung der vorliegenden Erfindung
mit Bezug auf die begleitenden Zeichnungen beschrieben, in denen:
-
1 allgemein
die Zusammenarbeit zwischen der Netzwerk-Ebene und der Applikations-Ebene in einem
Telekommunikationsnetz zeigt;
-
2 die
Konfiguration des Referenznetzes, das in der speziellen Ausführung verwendet
wird, detaillierter zeigt; und
-
3 die
Abfrage eines Netzelementes und die Kommunikation zwischen einer
Applikation und einem Netzelement unter Verwendung von Triggern
und Handles zeigt;
-
Detaillierte Beschreibung
der Erfindung
-
Die
allgemeine Architektur eines Telekommunikationsnetzes und der Dienstlogik
wird in 1 gezeigt. Das Telekommunikationsnetz
IP enthält
mehrere miteinander verbundene Netzelemente. Eine Dienstplattform SP
bietet Telekommunikationsdienste im Netzwerk an. Die Dienstplattform
SP kann entweder eine einzelne Applikation sein, die auf einem Teilnehmer-Endgerät oder auf
einem Server im Netz läuft,
oder sie kann eine verteilte Dienstplattform sein, die mehrere Softwaremodule
enthält,
von denen alle oder einige in Kombination einem Endanwender einen
bestimmten Dienst anbieten.
-
Netzelement
bezeichnet jedes Netzwerk-Gerät,
das über
Verbindungsmöglichkeiten
zum Netz verfügt, wie
Elemente des Teilnehmeranschlussnetzes und Elemente des Kernnetzes.
In den speziellen Ausführungen ist
das Telekommunikationsnetz ein IP-Netz, und der Begriff Netzelement umfasst
somit Router im Kern und am Rand des Netzes, Breitband-Zugangsserver,
Einrichtungen für
digitale Teilnehmerleitungen, Modems und ähnliches. Die Netzelemente
führen
alle Funktionen aus, die zur Netzwerkebene gehören. Andererseits ist die Dienstlogik
ein Satz von Applikationen einer höheren Ebene, die Mehrwertdienste
für Endanwender
bereitstellen und betrifft keine Dienste für Netzwerk-Verbindungsmöglichkeiten.
Die Dienstlogik repräsentiert
daher die Applikations-Ebene. Der Begriff Applikation bezeichnet
jedes Softwaremodul, das in der Dienstlogik läuft.
-
Gemäß der vorliegenden
Erfindung kommunizieren die Dienstlogik SP und die Netzelemente
des Netzes IP miteinander unter Verwendung von Triggern T und Handles
H. Ein Trigger T ist eine vom Netzelement zur Dienstlogik SP gesendete
Information, während
ein Handle ein von der Dienstlogik SP zu einem Netzelement gesendeter
Befehl ist. Spezieller ist ein Trigger eine Benachrichtigung, die
Daten enthält,
die bei Auftreten eines speziellen Ereignisses im Netz von einem
Netzelement zur Dienstlogik SP gesendet werden. Trigger sind somit
eine Möglichkeit
für Netzelemente,
Informationen bereitzustellen, die von der Dienstlogik SP verwendet
werden können
und irgendwie an Mehrwertdiensten beteiligt sind, die für den Endanwender
sichtbar sind. Ein Beispiel für
einen Trigger ist ein Präsenz-Trigger,
der von der Dienstlogik für
die Rechnungserstellung, für
Ankündigungen,
usw. verwendet wird. Ein Handle H ist ein von der Dienstlogik zu
einem Netzelement gesendeter Befehl. Diese Befehle fordern zum Beispiel
das Netzelement auf, einige Aktionen auszuführen, wie z.B. die Konfiguration
der Dienstqualität
QoS (Quality of Service), den Aufbau von Verbindungen, die Aktualisierung
einer Router-Tabelle,
usw., die das Netzelement aus allen seinen Vernetzungsmöglichkeiten
ausführen kann.
Handles können
ebenfalls nützliche
Informationen enthalten. Handles sind somit eine Möglichkeit,
Netzwerk-Ressourcen zum Nutzen einer Dienstplattform anzusteuern.
-
Die
Netzwerkarchitektur, die in der folgenden speziellen Ausführung verwendet
wird, ist in 2 detaillierter gezeigt. Sie
umfasst ein Teilnehmerendgerät
UT, das an ein ADSL-(Asymmetric Digital Subscriber Line)-Modem ADSL
angeschlossen ist. Über
eine digitale Teilnehmerleitung ist das ADSL-Modem mit der DSL-Einrichtung
DSLAM eines Zugangsanbieters verbunden. Die DSLAM ist an einen Breitband-Fernzugangs-Server
BRAS des Anbieters angeschlossen, und an den BRAS sind zwei IP-Netze
IP1, IP2 von zwei verschiedenen Netzbetreibern angeschlossen.
-
Jedes
dieser Geräte,
d.h. das Teilnehmerendgerät,
das ADSL-Modem,
die DSLAM und der BRAS, sowie die Netzelemente der beiden IP-Netze
kommunizieren mit der Dienstplattform SP unter Verwendung von Triggern
und Handles. Die Netzwerkebene und die Applikations-Ebene sind in
der Figur durch eine gestrichelte Linie getrennt.
-
Eine
Grundidee der vorliegenden Erfindung ist es, einen neuen Typ von
Management-Informations-Basis (MIB) einzuführen, welche die Trigger- und
Handles-Schnittstellen eines Netzelementes beschreibt. Über diese
MIB kann dann eine Applikations-Plattform das Protokoll SNMP (Simple
Network Management Protocol) verwenden, um Informationen an den
Schnittstellen des Netzelementes anzufordern, wie zum Beispiel:
- – Abruf
der Liste der unterstützten
Trigger und Handles.
- – Abruf
des Trigger-Ereignisses für
einen gegebenen Trigger.
- – Abruf
der Liste von unterstützten
Parametern (die für
jeden Parameter anzeigt, ob er optional oder obligatorisch ist)
für einen
gegebenen Trigger oder Handle.
-
Eine
Management-Informations-Basis (MIB) ist eine formale Beschreibung
eines Satzes von Netzwerk-Objekten, die unter Verwendung eines Protokolls,
wie SNMP, verwaltet werden können.
-
Eine
herkömmliche
MIB wird nur zum Zweck des Netzwerkmanagements eingesetzt, d.h.
zur Steuerung und Überwachung
der Netzelemente im Netz. Aus der Sicht eines Netzwerkmanagers findet
das Netzwerkmanagement zwischen zwei Haupttypen von Systemen statt:
Steuerungssysteme, die verwaltende Systeme genannt werden, und überwachte
und gesteuerte Systeme, die verwaltete Systeme genannt werden. Das
allgemeinste Verwaltungssystem wird Netzwerkmanagement-System (NMS)
genannt. Verwaltete Systeme können
Host-Rechner, Server oder Netzkomponenten, wie z.B. Router oder
intelligente Zwischenverstärker
enthalten.
-
Um
die Zusammenarbeit zu unterstützen,
müssen
zusammenarbeitende Systeme einen allgemeinen Rahmen einhalten und
eine gemeinsame Sprache, Protokoll genannt, unterstützen. Im
Rahmen des Internet-Netzwerk-Managements ist dieses Protokoll das
Simple Network Management Protocol (SNMP).
-
In
einem verwalteten Gerät
greifen spezialisierte Softwaremodule mit geringem Einfluss, Agents
genannt, auf Informationen über
das Gerät
zu und machen sie für
das NMS verfügbar.
Verwaltete Geräte
unterhalten Werte für
eine Anzahl von Variablen und melden diese nach Bedarf an das NMS.
Zum Beispiel kann ein Agent Daten melden, wie die Anzahl von Bytes
und Paketen, die in das Gerät
gelangen und es verlassen, oder die Anzahl von gesendeten und empfangenen
Rundsende-Nachrichten.
Im Rahmen des Internet-Netzwerkmanagement wird jede dieser Variablen
als verwaltetes Objekt bezeichnet. Ein verwaltetes Objekt ist alles,
was verwaltet werden kann, alles, auf was ein Agent zugreifen und
zum NMS zurückmelden
kann. Alle verwalteten Objekte sind in der Management-Informations-Basis
(MIB), einer Datenbank der verwalteten Objekte, enthalten.
-
Ein
NMS kann ein verwaltetes Gerät
steuern, indem es eine Nachricht an einen Agent des verwalteten Gerätes sendet,
wodurch es erforderlich wird, dass das Gerät den Wert eines oder mehrerer
seiner Variablen ändert.
Das verwaltete Gerät
kann auf Befehle reagieren, wie z.B. auf Befehle zum Einstellen
oder zum Abrufen. Die Befehle zum Einstellen werden vom NMS dazu
benutzt, das Gerät
zu steuern. Die Befehle zum Abrufen werden vom NMS zur Überwachung
des Gerätes
verwendet.
-
Die
MIB eines Netzelementes wird speziell für dieses Netzelement in einer
Hochsprache, wie ASN.1 (Abstract Syntax Notation One) definiert,
wobei es sich um eine formale Sprache handelt, mit der Nachrichten abstrakt
beschrieben werden, die zwischen verteilten Systemen ausgetauscht
werden. Die MIB definiert den Satz verwalteter Objekte, den dieses
NE unterstützt.
Diese Objekte sind als Baum organisiert, wo sie von vorhandenen
Objekten erben. Die ASN.1-Datei, welche die MIB-Beschreibung enthält, wird
dann zusammen mit Agents für
verwaltete Objekte, die zur Änderung
der verwalteten Objekte verwendet werden, durch ein Werkzeug compiliert.
Die resultierende Datei ist eine ausführbare Datei, die Teil der
Software des Netzelementes ist. Diese Software-Datei wird dann beim
Start vom NMS in das Netzelement heruntergeladen. Zur Laufzeit interagiert
das NMS mit Manager-Objekt-Agents unter Verwendung eines Protokolls
wie SNMP, um die Zustände
verwalteter Objekte zu ändern.
Im NMS gibt es ein Abbild der MIB, welches den aktuellen Zustand
der im Netzelement vorhandenen MIB widerspiegelt.
-
Gemäß der vorliegenden
Erfindung benutzt eine Applikations-Plattform die MIB, um die Trigger und Handles
abzufragen, die das Netzelement unterstützt. Dafür enthält die MIB neue verwaltete
Objekte, welche die unterstützten
Trigger und Handles beschreiben. Über NMS wird das Netzelement
konfiguriert, um in seine MIB die relevanten verwalteten Objekte
für die
unterstützten
Schnittstellen zur Applikations-Plattform
aufzunehmen. Trigger und Handles können somit als neue verwaltete
Objekte betrachtet werden, die als Erweiterung zur MIB des Netzelementes
hinzuzufügen
sind.
-
Das
Netzelement enthält
neben der MIB mit ihren neuen verwalteten Objekten einen oder mehrere Software-Agenten,
die dazu dienen, auf die neuen verwalteten Objekte für Trigger
und Handles zuzugreifen und sie zu unterhalten und auf Anforderung durch
eine Applikation die Information über die unterstützten Trigger
und Handles verfügbar
zu machen.
-
Ein
weiterer Aspekt der vorliegenden Erfindung besteht in der Einführung eines
neuen Moduls in die Applikations-Plattform, des Netzwerk-Schnittstellen-Entdeckungs-Moduls
(Network Interface Discovery, NID). Das NID-Modul hat folgende Aufgabe:
- – Gewinnung
der vollständigen
Information über
Trigger- und Handle-Schnittstellen, die von einem Netzelement unterstützt werden,
wozu ein Algorithmus verwendet wird, der die MIB systematisch abfragt.
Der Algorithmus sammelt die Informationen typischerweise, indem
er eine Sequenz von Anforderungen sendet, z.B. Abruf aller Schnittstellen,
für jede
Schnittstelle Abruf der Liste von Nachrichten, usw. und
- – Speichern
dieser Information in einem Datenmodell in der Applikations-Plattform,
wo sie von Applikationen abgerufen wird. Wenn eine Applikation überprüfen will,
ob ein Trigger oder Handle von einem bestimmten Netzelement unterstützt wird,
kann er dieses Datenmodell überprüfen.
-
Die
Kommunikation zwischen einer Applikation AP und einem Netzelement
NE unter Verwendung von Triggern T und Handles H ist in einer ersten
Ausführung
in 3 gezeigt. Ein Netzwerkmanagement-System NMS konfiguriert
in einem ersten Schritt 31 eine Liste von unterstützten Triggern
und Handles, indem es Netzelement NE mit einer Management-Informations-Basis MIB ausstattet,
welche die entsprechenden verwalteten Objekte enthält. Die
MIB wird in einer Datenbank in einem permanenten Speicher des Netzelementes
NE gespeichert. In Schritt 34 fragt ein Netzwerk-Schnittstellen-Entdeckungs-Modul
NID das Netzelement ab, indem es Anforderungen an das Netzelement
sendet, wie oben erläutert,
und Informationen über
die unterstützten
Trigger und Handles zurück
erhält.
Diese Informationen werden in Schritt 35 in einer Trigger-
und Handle-Datenbank THB in der Applikations-Plattform gespeichert,
zu der die Applikation AP gehört.
Wenn Applikation AP einen Befehl zum Netzelement senden möchte, fragt
es in Schritt 36 die Datenbank THB ab, um zu überprüfen, welche
Handle-Version das Netzelement NE unterstützt, und sendet den geeigneten
Handle H. Wenn ein spezielles Netzwerk-Ereignis auftritt, sendet das Netzelement
NE einen Trigger T zur Applikation AP, welcher der Applikation AP
anzeigt, dass dieses spezielle Ereignis aufgetreten ist.
-
Die
Trigger- und Handle-Datenbank THB kann jede Art von Datenmodell
aufweisen, das dazu geeignet ist, die Informationen über Trigger
und Handles, die von einem oder mehreren Netzelementen empfangen wurden,
auf strukturierte Weise zu speichern, und kann auf einem permanenten
Speicher beliebiger Art implementiert werden.
-
Das
NID-Modul, wie oben beschrieben, kann Teil einer einzelnen Applikation
oder einer verteilten Applikations-Plattform sein. Trotzdem können seine
Funktionen auch direkt in einer einzelnen Applikation enthalten
sein, statt ein gesondertes Softwaremodul bereitzustellen.
-
Die
Schnittstellenabfrage gemäß der vorliegenden
Erfindung kann vorteilhaft in Kombination mit einem Anmelde/Benachrichtigungs-Mechanismus
eingesetzt werden, wie in der ebenfalls eingereichten europäischen Patentanmeldung
mit dem Titel "Trigger
between Service Platform and Network Element" unter der Anmeldenummer
EP 01 440 129.3 , eingereicht am
10.5.2001, beschrieben.
-
Das
Grundkonzept dieses Anmelde-/Benachrichtigungs-Mechanismus ist,
dass eine Applikation sich bei einem Netzelement für Trigger
anmeldet, an deren Empfang sie interessiert ist, indem sie eine
entsprechende Anmelde-Anforderung an das Netzelement sendet. Die
Anmelde-Anforderung spezifiziert das Ereignis, von dem die Applikation
zu benachrichtigen ist und die Parameter, an deren Empfang die Applikation
interessiert ist. Bei Auftreten des Ereignisses des spezifizierten
Typs erzeugt das Netzelement eine Trigger-Nachricht, welche die
angeforderten Trigger-Parameter enthält, und sendet sie an die angemeldete
Applikation.
-
Um
den Anmelde-/Benachrichtigungs-Mechanismus am besten zu nutzen,
ist es von Vorteil, dass die Applikation die Schnittstellen des
Netzelementes zuerst abfragt, um zu sehen, welche Trigger das Netzelement zur
Anmeldung anbietet und welche Trigger-Parameter zur Verfügung stehen.
In dem in 3 gezeigten Beispiel bedeutet
dies, dass das Netzwerk-Schnittstellen-Entdeckungs-Modul
NID in Schritt 34 zum Netzelement NE Abfrage-Anforderungen sendet,
wie z.B. "Abfrage
der Liste unterstützter
Trigger und Handles" und "Abfrage der Liste
unterstützter
Parameter für
einen gegebenen Trigger".
Die vom Netzelement NE zurück
erhaltenen Informationen werden dann in der Datenbank THB gespeichert.
Die Applikation AP kann somit in die Datenbank THB sehen, um festzustellen,
welche Trigger und Trigger-Parameter das Netzelement NE anbietet. Dann
meldet sich die Applikation AP beim Netzelement für einen
bestimmten Trigger an und bei Auftreten des entsprechenden Trigger-Ereignisses
sendet das Netzelement NE den angeforderten Trigger T an die angemeldete
Applikation AP.
-
Das
folgende Beispiel zeigt, wie Trigger oder Handles als verwaltetes
Objekt unter Verwendung von ANS.1 definiert werden können. Das
Beispiel beschreibt Radius-, COPS (Common Open Policy Service)-
und Durchmesser-Handles für
einen Breitband-Fernzugangs-Server
(BARS), wie in 2 gezeigt. Die Figuren dienen
zur Illustration nur eines Beispiels und können sich für andere Beispiele unterscheiden.
Für die
Accounting-Attribute
wird dieselbe Attribut-ID (d.h. Benutzername = Attribut 1, acct-statustype
= 40) verwendet wie in RFC2139 für
Radius-Accounting.
-
-
-
Nachdem
die Erfindung nun bezüglich
einer bevorzugten Ausführung
beschrieben wurde, ist es für
einen Fachmann klar, dass verschiedene weitere Änderungen, Weglassungen und
Hinzufügungen
möglich
sind, ohne vom Umfang der Erfindung abzuweichen. Es muss darauf
hingewiesen werden, dass zum Beispiel die Einführung der Funktionalität des NID-Moduls
in die Applikations-Plattform nicht notwendigerweise für die Implementation
der Erfindung erforderlich ist. Statt die Schnittstelle eines Netzelementes
vorher abzufragen und die Information über die Schnittstelle in einem
Datenmodell zu speichern, ist es auch möglich, ein Netzelement jedes
Mal, wenn ein Handle gesendet werden soll, oder wenn eine Anmeldung
bei einem Trigger durchgeführt werden
soll, zu fragen, ob das Netzelement diesen Trigger oder Handle unterstützt und
welche Version und Parameter es unterstützt. Es wird jedoch bevorzugt,
alle unterstützten
Trigger und Handles vorher abzufragen, um den Verkehr im Netz zu
minimieren.
-
Eine
weitere vorteilhafte Modifikation ist die Einführung eines zusätzlichen
Softwaremoduls, des Netzwerk-Schnittstellen-Anpassungs-Moduls
(Network Interface Adaption, NIA) in die Applikations-Plattform.
Das NIA-Modul hat folgende Aufgaben:
- – Umsetzung
von Befehlen, die von Applikationen ausgegeben werden, auf eine
vom Protokoll unabhängige
Weise, z.B. Einstellung der NAT-Tabelle, um Verkehr zwischen (IP-Adresse a, Anschluss
x) und (IP-Adresse b, Anschluss y) in Richtung der speziellen Protokollnachricht
oder des speziellen Handles für das
gegebene Netzelement zu erlauben.
- – Umsetzung
von Triggern von den Netzelementen, z.B. einer RADIUS-Accounting-Nachricht
oder jedes anderen Triggers, in die vom Netzwerk unabhängige Darstellung
von Triggern, die intern in der Applikations-Plattform benutzt wird.
