-
Netzwerkvorrichtungen,
z. B. Router, werden umfassend getestet, um sicherzustellen, dass
fehlerhafte Übertragungen
und schwere Fehler minimiert sind. Eine Vielzahl von Testvorrichtungen
sind auf dem Markt erhältlich,
einschließlich
des ROUTER TESTER von AGILENT TECHNOLOGIES, Anmelderin der vorliegenden
Anmeldung. Derartige Testvorrichtungen überwachen üblicherweise das Ansprechverhalten
von Routern auf eine Vielzahl von simulierten Eingaben.
-
Der
Prozess des Leitens bzw. Routens kann schnell so zusammengefasst
werden, dass ein Knoten den Weg zu jedem möglichen Bestimmungsort findet.
Routen findet überall
statt, von Schicht 1 (der physischen Schicht) aufwärts. Das
Routen, das die meisten Leute kennen, findet jedoch bei Schicht
3 (der Netzwerkschicht) statt, und somit erfolgt hier nur eine Bezugnahme
auf ein Schicht-3- (und im Einzelnen) Internetprotokoll-(IP)Routen.
Router verwenden Tabellen, um zu bestimmen, wo Pakete hingeleitet
werden sollen. Ein Aktualisieren dieser Tabellen ist eine Funktion,
die durch Leitprotokolle durchgeführt wird. Jeder Router spricht auf
ein oder mehr Protokolle an.
-
Protokolle
zum Austauschen von Leitinformationen verbinden mehrere Router auf
der ganzen Welt, um denselben eine gemeinsame Ansicht des Netzwerkes
durch ihre heterogenen, jedoch im Allgemeinen vereinbaren Leittabellen
zu liefern. Leittabellen speichern alle Informationen, die für den Router
notwendig sind, um jeden Bestimmungsort in dem Netzwerk unabhängig von
der Größe zu erreichen.
Es existiert eine große Vielzahl
von verschiedenen Leitprotokollen, die verwendet werden, um über ein
Netzwerk zu den Leittabellen beizutragen. Mit Hilfe von Protokollen
wie z. B. BGP, OSPF, RIP und ISIS wird ein korrektes und kohärentes Bild
des Netzwerks an alle Router in dem Netzwerk übermittelt.
-
Bekannte
Routertester simulieren einen Netzwerkverkehr, wobei sie speziell
erzeugte „Testpakete" von Daten verwenden,
die typisch für
die tatsächlichen
Daten sind, die in dem Netzwerk vorliegen. Diese Testpakete werden über ein
zu testendes Netzwerk an die Netzwerkvorrichtung gesendet. Parameter,
die durch Verkehrsimulatorsysteme (einschließlich ROUTER TESTER) getestet
werden, umfassen eine Leitprüfung,
ein Erreichen von Dienstgüte-(QoS)
Niveaus unter Last und eine korrekte Zusammenarbeit mit anderen
Vorrichtungen. Viele dieser so genannten „Paketlader" testen auch die
Fähigkeit
der Netzwerkvorrichtung, sich an Protokolle zu halten, indem sie
Nachrichten gemäß den Protokollen
formulieren und senden.
-
1 ist ein Blockdiagramm
eines Verkehrsimulatortestsystems 100. Insbesondere ist
das Verkehrsimulatortestsystem 100 eine allgemeine Darstellung
des ROUTER TESTER, der von AGILENT TECHNOLOGIES angeboten wird.
ROUTER TESTER ist nur ein Beispiel eines Routertestsystems und wird
insbesondere angeboten als Mehrtorverkehrerzeugungs-, Protokollemulations-
und Analysetestsystem zum Prüfen
der Leistung von Unternehmens-, Metro/Edge-, Kernleit- und optischen
Netzwerkvorrichtungen. Das System weist allgemein eine Mehrzahl
von Protokollemulationskarten 102n auf, die mit einem zu
testenden System, in diesem Fall einem Router 104, verbunden
sind. Jede der Protokollemulationskarten 102n weist allgemein
einen Prozessor mit zugeordnetem Speicher und I/O auf. Die Protokollemulationskarten 102n werden
durch einen Computer 106, wie z. B. einen PC, auf dem eine
WINDOWS-Umgebung
läuft,
gesteuert. Der Computer 106 spricht auf eine Schnittstelle 108,
wie z. B. eine graphische Benutzerschnittstelle, an.
-
Die
Testpakete, die durch die Protokollemulationskarten 102n erzeugt
werden, werden gemäß den Regeln
und Interpretationen von Kommunikationsprotokollen erzeugt, wie
z. B. denjenigen, die durch die vielen Standardkörper in der Industrie definiert
sind. Es befinden sich viele Kommunikationsprotokolle in Gebrauch
und neue Protokolle werden weiterhin entwickelt. Normalerweise werden
neue Protokolle anfangs durch Ausrüstungshersteller entwickelt
und weisen eine proprietäre
Beschaffenheit auf. Oft werden die Protokolle nachfolgend durch
Standardeinrichtungen zur verbreiteten Implementierung in der Industrie übernommen.
-
Die
aktuelle Softwarearchitektur, die Verkehrsimulatortestsystemen zugeordnet
ist, erfordert eine feste Codierung aller Teile der Protokollemulationslösung, einschließlich graphischer
Benutzerschnittstelle, Skript-API, Konfigurations- und Steuerkomponenten
und der Protokollzustandsmaschine selbst. Die feste Codierung, die
für jedes
Protokoll erforderlich ist, hat zum Einsatz einer großen Menge
menschlichen Talents geführt,
um den großen
Codekörper
zu erzeugen. Ein Großteil
dieses Codes ist dem Bilden einer Schnittstelle zwischen einem Computer 106 und
jeder neuen Protokollemulationskarte 102n gewidmet.
-
Der
herkömmliche
Lösungsansatz
zum Bilden einer Schnittstelle zwischen dem Computer 106 und
jeder neuen Protokollemulationskarte 102n erfordert, dass
Verfahren und zugeordnete Parameter zu der Zeit, zu der die Schnittstelle
in einer Schnittstellenbeschreibungssprache (IDL) geschrieben und
fest codiert wird, bekannt sind. Unter diesem Paradigma werden ständig jedes
Mal neue Verfahren und Parameter erzeugt, wenn neue Protokollemulationen
geschrieben oder alte Protokolle erweitert werden. Dies hat zu einer
enormen API (Anwendungsprogrammierschnittstelle) geführt, die
viele hundert Verfahren und Parameter enthält, was zu einem Codekörper führt, dessen
Unterhalt teuer ist. Ferner führen
die bekannten Lösungsansätze dazu, dass
die API an mehreren unterschiedlichen Schichten nachgebildet wird,
wodurch sich die Probleme vergrößern. Somit
erfordert jede Veränderung
der API (egal wie gering) die Aktualisierung einer beträchtlichen
Codemenge und unterschiedlicher Ebenen in dem System. Eine Nebenwirkung
dieses Lösungsansatzes
besteht darin, dass eine einzigartige GUI für jedes Protokoll und jede
Aktualisierung desselben erzeugt werden muss. Genau wie bei der
API gilt, dass die Anzahl der benötigten GUI-Implementierungen mit der Anzahl von
Protokollen wechselt.
-
Es
werden nun Anstrengungen unternommen, allgemeine Systeme zu entwerfen,
die einige der genannten Probleme abmildern. Ein Beispiel ist beschrieben
in der ebenfalls anhängigen
US-Patentanmeldung Seriennummer: 10/266,507, Veröffentlichungsnr.: US20040068681
A1, mit dem Titel: Building packets of data. Die US20040068681 A1,
die hier durch Bezugnahme aufgenommen ist, verwendet eine externe
XML-Protokollbeschreibung,
um eine allgemeine PDU-Codier/Decodiermaschine zu treiben. Ein nächster Schritt
besteht darin, eine allgemeine Schnittstelle mit den Protokollemulatoren
herzustellen, die keinen neuen Code oder fest codierte Schnittstellenveränderungen
für jeden
neuen Emulator oder eine Veränderung
daran erfordern.
-
Ein
bekannter Lösungsansatz
für dieses
Problem ist die Verwendung einer Schnittstellendefinitionssprache
(IDL), wie z. B. DCOM oder CORBA. IDLs haben sich jedoch als ungeeignet
erwiesen, da dieselben erfordern, dass alle Details jeder Schnittstelle
zum Kompilierungszeitpunkt bekannt sind. Eine weitere Option ist
die Verwendung von ASN.1 – einer
Sprache zum Definieren einer beliebigen Datenstruktur. Bekannte ASN.1-Kompilierer
erzeugen Schnittstellencode zum Codieren und Decodieren derartiger
Strukturen. Wie bei IDLs handelt es sich bei ASN.l jedoch um eine
Kompilierungszeitlösung,
die einen speziell geschriebenen Code für jede Schnittstelle erfordert.
Eine weitere Option ist die Verwendung eines der verfügbaren XML-Datenmodelle,
wie z. B. DOM (Dokumentobjektmodell). XML-Daten werden jedoch als
Textdateien übertragen, die
eine ineffiziente Verwendung von Bandbreite aufweisen. Ferner erfordern
XML-Daten normalerweise sehr prozessorintensive Berechnungen zusammen
mit einem zeitaufwendigen syntaktischen Analysieren. Ferner ist
die Navigation einer DOM-Struktur langsam und stellt typischerweise
nicht tabellarische Daten dar (was bei Protollemulatorschnittstellen
vorwiegend der Fall ist).
-
Dementsprechend
haben die Erfinder der vorliegenden Erfindung einen Bedarf an einem
neuen Schnittstellenmechanismus erkannt, der in der Lage ist, alle
Befehle, Konfigurationsdaten und Ausgangssignale von einer Protokollemulation
darzustellen. Ferner sollte ein derartiger Mechanismus gleichermaßen für hierarchische
Daten wie für
tabellarische Daten geeignet sein.
-
Es
ist die Aufgabe der vorliegenden Erfindung, ein Verfahren zum Übertragen
von Daten, ein Verfahren zum Kommunizieren mit einer Protokollemulation,
ein System zum Übertragen
von Daten und ein System zum Steuern eines Protokollemulators mit
verbesserten Charakteristika zu schaffen.
-
Diese
Aufgabe wird durch ein Verfahren gemäß Anspruch 1, ein Verfahren
gemäß Anspruch
15, ein System gemäß Anspruch
33 sowie ein System gemäß Anspruch
45 gelöst.
-
Ein
Verständnis
der vorliegenden Erfindung kann aus der folgenden detaillierten
Beschreibung bestimmter Ausführungsbeispiele
der vorliegenden Erfindung zusammengenommen mit den beiliegenden
Zeichnungen gewonnen werden. Es zeigen:
-
1 ein
Blockdiagramm eines Verkehrsimulatortestsystems;
-
2 ein
Blockdiagramm, das allgemein ein Verfahren zum Übertragen von Daten gemäß einem
Ausführungsbeispiel
der vorliegenden Erfindung veranschaulicht;
-
3 ein
Blockdiagramm eines Protokollemulationssystems gemäß einem
bevorzugten Ausführungsbeispiel
der vorliegenden Erfindung;
-
4 ein
Blockdiagramm, das die Verwendung einer Paketdefinition veranschaulicht,
um ein Paketreferenzmodell und ein Paketobjekt gemäß einem
Ausführungsbeispiel
der vorliegenden Erfindung zu erzeugen;
-
5 ist
ein Flussdiagramm eines Verfahrens zum Herstellen eines Paketobjekts;
-
6 eine
Bildschirmaufnahme einer Schnittstelle, die basierend auf einer
Tabellenstruktur, die einer Paketdefinition definiert ist, aufgebaut
ist; und
-
7 eine
Bildschirmaufnahme einer Schnittstelle, die basierend auf einem
Satz von Werten, die in einer Paketdefinition definiert sind, aufgebaut
ist.
-
In
der Beschreibung, die im Folgenden enthalten ist, bezeichnet die
Verwendung eines kleinen „n" neben einem Elementidentifizierer
eine nicht spezifische Instanz des Elements anstelle eines spezifischen
Elements, wie es in den Figuren gezeigt ist oder in der Beschreibung
mit einem nicht kursiv geschrieben Buchstaben neben der Elementnummer
erörtert
ist.
-
Es
wird nun Bezug genommen auf Ausführungsbeispiele
der vorliegenden Erfindung, wobei Beispiele derselben in den beiliegenden
Zeichnungen veranschaulicht sind, wobei gleiche Bezugszeichen sich
durchweg auf gleiche Elemente beziehen. Die folgende detaillierte
Beschreibung präsentiert
Verfahren, die durch Routinen und symbolische Darstellungen von
Operationen von Datenbits in einem computerlesbaren Medium, zugeordneten
Prozessoren, Datenerzeugungs- und – erfassungskarten und dergleichen
ausgeführt
sein können.
Eine Routine wird hier und allgemein als eine Sequenz von Schritten
oder Aktionen verstanden, die zu einem gewünschten Ergebnis führen, und
umfasst somit Fachtermini wie „Programm", „Objekte", „Funktionen", „Subroutinen" und „Prozeduren". Diese Beschreibungen
und Darstellungen sind die Mittel, die von Fachleuten verwendet
werden, um die Materie ihrer Arbeit anderen Fachleuten wirksam zu
vermitteln. Aus praktischen Gründen
wird das Wort „Netzwerk" im Folgenden in
der Beschreibung und den Ansprüchen
verwendet, um sich auf eines oder mehr der Folgenden zu beziehen:
ein Kommunikationsnetzwerk, eine Netzwerkvorrichtung, eine andere
Kommunikationsvorrichtung und einen beliebigen Aspekt oder Aspekte
eines Kommunikationssystems, das unter Verwendung von Datentestpaketen
getestet werden kann.
-
Ausführungsbeispiele,
die Verfahren aufweisen, werden mit Bezug auf eine Implementierung
bei einem Routertester beschrieben, der eine ähnliche Konfiguration wie der
AGILENT ROUTER TESTER aufweist, aber die Verfahren, die hier aufgeführt sind,
können
bei jedem beliebigen einer Vielzahl von Routertestern wirksam sein.
Genauer gesagt beziehen sich die hier vorgestellten Verfahren nicht
inhärent
auf eine bestimmte Vorrichtung; stattdessen können verschiedene Vorrichtungen
bei Routinen gemäß den hier
dargestellten Lehren verwendet werden. Insbesondere können die
Verfahren, die hier für
eine Übertragung
von Daten von einer Vorrichtung zu einer anderen beschrieben sind,
obwohl dieselben mit Bezug auf eine Routertesterfunktion beschrieben
sind, in dem Datenkommunikationsgebiet im Allgemeinen anwendbar
sein. Maschinen, die die hier beschriebenen Funktionen ausführen können, umfassen
diejenigen, die durch Unternehmen wie AGILENT TECHNOLOGIES, INC.,
HEWLETT PACKARD und TEKTRONIX, INC. sowie andere Hersteller von
Kommunikationsausrüstung
hergestellt werden.
-
Mit
Bezug auf die hier beschriebene Software werden Durchschnittsfachleute
erkennen, dass eine Vielzahl von Platt formen und Sprachen zum Erzeugen
von Software zum Durchführen
der hier umrissenen Prozeduren existiert. Ausführungsbeispiele der vorliegenden
Erfindung können
unter Verwendung einer beliebigen einer Anzahl von Varietäten von
C, einschließlich
C++, implementiert sein. Durchschnittsfachleute werden jedoch auch
erkennen, dass die Auswahl der genauen Plattform und Sprache oft
durch die speziellen Vorgaben des tatsächlichen hergestellten Systems
vorgegeben sind, sodass es sein kann, dass bei einem Systemtyp funktioniert,
was bei einem anderen System nicht effizient ist. Es sei ebenfalls
darauf hingewiesen, dass die hier beschriebenen Routinen und Berechnungen
nicht darauf beschränkt
sind, als Software auf einem Computer ausgeführt zu werden, sondern auch
in einem Hardwareprozessor implementiert sein können. Zum Beispiel könnten die
Routinen und Berechnungen mit HDL (Hardwareentwurfssprache) bei
einer ASIC oder bei einer FGPA unter Verwendung einer Vielzahl von
Entwurfswerkzeugen implementiert sein.
-
Verfahren
zum Übertragen
von Daten
-
2 ist
ein Blockdiagramm, das allgemein ein Verfahren zum Übertragen
von Daten gemäß einem Ausführungsbeispiel
der vorliegenden Erfindung veranschaulicht. Das veranschaulichte
Verfahren dient zum Übertragen
von Daten von einem ersten Ort 200a zu einem zweiten Ort 200b.
Im Zusammenhang mit Protokollemulatoren, wie es in 1 gezeigt
ist, kann der erste Ort 200a als ein Computer 106 (oder „Client") angenommen werden,
auf dem die Steueranwendungen laufen, und der zweite Ort kann als
die Protokollemulationskarte 102n (oder „Server") angenommen werden,
auf dem Dienstanwendungen laufen. Die Steueranwendungen umfassen
die graphische Benutzerschnittstelle zusammen mit Kommunikationsroutinen
zum Senden und Empfangen von Daten. Die Dienstanwendungen umfassen
Protokollemulationsanwendungen zusammen mit Kommunikationsroutinen
zum Senden und Empfangen von Daten.
-
Aus
praktischen Gründen
werden die Datenstrukturen, die durch die beschriebenen Ausführungsbeispiele
der vorliegenden Erfindung verwendet werden, als „Pakete" bezeichnet. Ein
Paket kann als eine flexible, kommentierte Datenstruktur betrachtet
werden, die Befehle, Konfigurationsdaten und Ausgangssignale von
einer beliebigen Routine darstellen kann. Pakete, die durch den
Client erzeugt werden, enthalten: Befehle; Sitzungsdaten; und Topologie.
Pakete, die durch die Protokollemulationskarte erzeugt werden, enthalten:
Statistik; Topologie; und Nachrichtenverfolgung.
-
Das Übertragungsverfahren,
das in 2 veranschaulicht ist, beginnt mit einer Paketdefinition 202a (hier
auch als eine „Definition" oder „Beschreibung" bezeichnet). Eine
Paketdefinition 202n liefert eine Beschreibung der Elemente
von einem oder mehr Paketen zusammen mit Attributen davor. Die bevorzugte
Datenstruktur eines Pakets ist hierarchisch, wobei jeder Knoten
einen Wert, Unterknoten, eine Funktion, ein Array von Werten oder
eine Tabelle von Werten enthalten kann. Eine Paketdefinition 202a kann
einfach eine Textdatei sein, die eine Liste von Paketen liefert
und die Elemente (hier als die „Knoten" bezeichnet), die jedes Paket bilden,
den Typ jedes Knotens und die Beziehung der Knoten untereinander
spezifiziert. Jeder Knoten kann unter Verwendung von beschreibenden
Attributen (Beispiele sind im Folgenden erörtert) kommentiert sein.
-
Es
kann bevorzugt, aber nicht notwendig, sein, die Paketdefinition 202a in
XML zu formulieren. Genauer gesagt ist es erwünscht, die Paketbeschreibung
in einem leicht zugänglichen
Format zu formatieren, um die Erzeugung und Modifizierung derselben
zu erleichtern. Die verschachtelte Tag-Struktur, die durch XML geliefert wird,
erleichtert die Dokumentierung von hierarchischen Beziehungen und
Tabellenstrukturen. Die Paketdefinition 202a ist allgemein
an dem ersten Ort 200a gespeichert und wird zur Laufzeit
durch Anwendungen, die an dem ersten Ort 200a laufen, wiedergewonnen.
-
Die
Paketdefinition 202a wird syntaktisch analysiert, um ein
Paketreferenzmodell 204a (auch als ein „Referenzmodell" bezeichnet) zu erzeugen.
Allgemein ist das Paketreferenzmodell eine Datenstruktur, wie bei C++,
aus der Instanzen eines Pakets, z. B. das Paketobjekt 206b,
erzeugt oder instantiiert werden können. Die vielleicht ähnlichste
analoge Struktur wäre
ein allgemeiner Typ in c++. Ein Unterschied
liegt darin, dass ein Paket während
einer Laufzeit eingebracht werden kann, während allgemeine Typen bei
einer Kompilierung definiert werden müssen. Bei Paketen ist der Typ
durch das Referenzmodell 204a definiert, von dem das tatsächliche
Paket abgeleitet ist. Bei der Verwendung kann es sich als vorteilhaft
erweisen, alle Paketdefinitionen 202n bei einem Systemstart
syntaktisch zu analysieren, um ein Referenzmodell aller möglichen
Pakete, die während des
Betriebs erforderlich sein können,
zu erzeugen. Falls Zeit und Speicherung berücksichtigt werden müssen, kann
es jedoch ratsam sein, nur diejenigen Referenzmodelle zu erzeugen,
bei denen es wahrscheinlich ist, dass sie für die aktuelle Sitzung benötigt werden.
-
Paketobjekte
können
unter Verwendung einer Paket-API, die im Folgenden beschrieben ist,
die eine allgemeine Schnittstelle zum Arbeiten mit Paketdaten liefern
kann, verwaltet werden. Im Zusammenhang mit der vorliegenden Erfindung
besteht ein Verfahren zum Arbeiten mit Paketen darin, dieselben
für eine Übermittlung
an den zweiten Ort 202b zu serialisieren. Ein Paket kann
zu einer Vielzahl von Formen serialisiert werden, einschließlich XML,
das für
Sichern/Wiederherstellen-Zwecke geeignet ist, und einer binären Form,
die zur Kommunikation mit anderen Orten geeignet ist. Konzeptionell
kann eine Serialisierung betrachtet werden als ein Abziehen der
Daten von der Datenstruktur und ein Bilden einer linearen Datei
oder eines Datenstroms zur Übertragung.
Eine ausreichende Datenstruktur wird geliefert, um das Referenzmodell 204n zu
identifizieren, das verwendet werden sollte, um den Binärstrom zu
decodieren und das Paket auf der Empfangsseite wiederherzustellen.
Während
dieser Wiederherstellung werden die Strukturinformationen, die in
dem Referenzmodell 204n enthalten sind, verwendet, um die
Daten in dem Binärstrom
syntaktisch zu analysieren.
-
Dementsprechend
ist der zweite Ort 200b mit einer Kopie der Paketdefinition 202a ausgestattet – die als
die Paketdefinition 202b gezeigt ist. Der zweite Ort 200b analysiert
die Paketdefinition 202a syntaktisch, um ein Referenzmodell 204b zu
erzeugen, bei dem es sich um eine Kopie des Referenzmodells 204a handeln sollte.
Auf den Empfang der Binärdaten 208 hin
bildet der zweite Ort 200b durch ein Instantiieren des
Paketreferenzmodells 204b und ein Bestücken der resultierenden Datenstruktur
mit den Binärdaten 208 ein
Paketobjekt.
-
Ein ähnlicher
Prozess kann verwendet werden, um Paketobjekte zu bilden. Die Paketdefinition 202a kann
verwendet werden, um eine graphische Benutzerschnittstelle mit den
geeigneten Eingabemechanismen, z. B. Texteingabefelder, Wahlknöpfe, usw.
...., für
jedes der definierten Elemente zu erzeugen. Wenn der Benutzer die
gewünschten
Eingangsdaten liefert, wird das Referenzmodell 204n instantiiert,
und das Paketobjekt 206n wird mit den Eingangsdaten bestückt. Vorteilhafterweise
kann eine allgemeine API entwickelt werden, wobei Beispiele derselben
hier im Folgenden offenbart sind, die die Erzeugung und Aufrechterhaltung
eines beliebigen Paketobjekts 206n, für das eine Paketdefinition 202n bereitgestellt
ist, handhaben kann.
-
Im
Gegensatz zu auf IDL basierenden Lösungen ist ein Paket außerhalb
des kompilierten Codes definiert und verwendet eine allgemeine API,
die nicht verändert
werden muss, wenn neue Pakete definiert werden. Dies ermöglicht es,
einen Anwendungsrahmen herzustellen, der zukünftigen Protokolllösungen gerecht werden
kann, ohne den Rahmen verändern
oder vergrößern zu
müssen.
Dies erlaubt auch die Erzeugung einer stabilen Schnittstelle, auf
der Dritte oder Kunden ihre eigenen Lösungen aufbauen können. Im
Gegensatz zu herkömmlichen
XML-Lösungen
wird die Paketstruktur einmal im Voraus definiert – nicht
für jedes
empfangene Datenpaket. Benötigte
Paketreferenzmodelle können
zum Anwendungsstartzeitpunkt erzeugt werden, was die Notwendigkeit
vermindert, ständig
XML syntaktisch zu analysieren. Pakete können für eine effiziente Navigation
konzipiert sein, und ein Suchen wird im Gegensatz zu XML-DOM minimiert.
Pakete können
für ein effizientes
Binärcodieren
und -decodieren konzipiert sein, die verglichen mit XML-Text relativ
kleine Binärdatenpakete
zur Übermittlung
zwischen Softwaresystemen benötigen.
Pakete können
konzipiert sein, um tabellarische Daten zu umfassen, die eine natürliche Anpassung
an viele Anwendungen liefern.
-
Verwendung
von Paketen bei einem Protokollemulator
-
3 ist
ein Blockdiagramm eines Protokollemulationssystems 300 gemäß einem
bevorzugten Ausführungsbeispiel
der vorliegenden Erfindung. Das System 300 weist allgemein
einen Host 302, wie z. B. einen Personalcomputer, auf dem
eine Version des MICROSOFT-WINDOWS-Systems läuft, und zumindest eine Protokollemulatorkarte 304 (auch
als ein Protokollemulator bezeichnet) auf, die im Allgemeinen einen
Prozessor mit zugeordnetem Speicher und I/O-Einrichtungen aufweist.
Es kann sich als vorteilhaft erweisen, wenn der Protokollemulator
in seiner Architektur einem Personalcomputer ähnelt. Gemäß zumindest einem Ausführungsbeispiel
kann der Host 302 als ein Client konfiguriert sein, wohingegen
der Protokollemulator 304 als ein Server konfiguriert sein
kann.
-
Auf
dem Host 302 läuft,
zusammen mit anderen Anwendungen und dem Betriebssystem, eine Anwendung 306,
die Routinen für
die Steuerung des Protokollemulators 304 und speziell zur
Kommunikation mit der Protokollemulatorkarte 304 liefert.
Gemäß zumindest
einem Ausführungsbeispiel
handelt es sich bei der Anwendung um eine allgemeine protokollunabhän gige Anwendung.
Dies bedeutet, dass die Anwendung 306 bevorzugt keine protokollspezifische
Funktionalität
aufweist. Eine derartige Funktionalität wird tatsächlich dynamisch unter Verwendung
der Paketdefinitionen 202n erzeugt. Die Anwendung 306 ist
für die
Erzeugung, Aufrechterhaltung und Verwendung des Paketreferenzmodells 204n (siehe 2)
zuständig,
sowie außerdem
für Serialisierung, Übertragung,
Empfang und Deserialisierung der Daten, die in Instanzen des Referenzmodells, z.
B. den Paketobjekten 206n, enthalten sind. Wie bereits
erwähnt,
kann es bevorzugt werden, für
diese Funktionen eine API-artige Schnittstelle bereitzustellen,
wodurch eine einzige allgemeine Schnittstelle für jede unterschiedliche Protokollemulation
bereitgestellt wird.
-
Eine
graphische Benutzerschnittstelle 310 ist derart bereitgestellt,
dass die Anwendung 306, wenn ein Benutzer anfordert, dass
eine Protokollemulation gestartet wird, mit einem Client 312 in
der graphischen Benutzerschnittstelle 310 in Wechselwirkung
tritt, um Formulare für
die Eingabe von Parametern, die benötigt werden, um den Protokollemulator 304 zu
steuern, anzuzeigen. Dies kann unter Verwendung der Paketdefinition 202n oder
des Paketreferenzmodells 204n (siehe 2)
erreicht werden. Wenn die geeigneten Daten eingegeben worden sind,
erzeugt die Anwendung 306 eine Instanz des Referenzmodells 204n,
um ein Paketobjekt 206n zu bilden. Die Anwendung 306 serialisiert
das Paketobjekt 206n und sendet das serialisierte Objekt an
den Protokollemulator 304.
-
Auf
dem Protokollemulator 304 läuft unter anderem eine Anwendung 308,
die Module zur Emulation von ausgewählten Protokollen 309n umfasst.
Gemäß zumindest
einem bevorzugten Ausführungsbeispiel
umfasst die Anwendung 308 Routinen zur Kommunikation mit
dem Host 302 unter Verwendung von Paketen. Allgemein kann
es bevorzugt sein, dass die Anwendung 308 Routinen umfasst,
die denjenigen ähnlich
sind, die in der Anwendung 306 enthalten sind. Dies kann
erreicht werden durch die Erzeugung von allgemeinen API-artigen
Routinen, die mit Paketen eine Schnittstelle bilden. Beispiele für derartige
Routinen werden im Folgenden geliefert.
-
Dem
Protokollemulator 304 sollten periodisch aktualisierte
Kopien der Paketdefinitionen 202n geliefert werden. Es
kann von Vorteil sein, dass der Host 302 die Definitionen 202n bei
jedem Starten an den Protokollemulator 304 liefert. Der
Protokollemulator 304 erzeugt auf den Empfang der Paketdefinitionen 202n hin
einen Satz von Paketreferenzmodellen 204n, aus denen Paketobjekte 206n instantiiert
werden können.
Wenn ein serialisiertes Paketobjekt von dem Host 302 empfangen
wird, wird ein neues Paketobjekt basierend auf dem zugeordneten
Paketobjekt 206n instantiiert. Dieses Objekt wird dann
verwendet, um die Daten zu liefern, die von Protokollemulationsroutinen
benötigt
werden, die auf dem Protokollemulator 304 laufen. Wenn
somit dem Protokollemulator 304 neue Protokollemulationen
hinzugefügt
werden, muss nur eine neue Paketdefinition 202n definiert
werden, um eine Kommunikation zwischen dem Host 302 und
dem Protokollemulator 304 (und dem Modul 309n)
zu erlauben.
-
Pakete
-
Obwohl
sich die folgende Erörterung
auf ein Ausführungsbeispiel
eines Paket konzentriert, werden Durchschnittsfachleute erkennen,
dass Abweichungen von der beschriebenen Paketstruktur möglich sind
und trotzdem in den Schutzbereich der Erfindung fallen. Bei dem
beschriebenen Ausführungsbeispiel
weisen Pakete allgemein einen Kopfblock und einen Satz von Elementen
auf. Die Elemente gehören
im Allgemeinen zu zwei Kategorien, Behälterelementen, die eine Struktur
liefern, und Datenelementen, die einen Wert oder Reihen von Werten
speichern. Ein Beispiel eines Satzes von Element- (nicht „Knoten"-) Typen für ein Paket sind in TABELLE
1 gezeigt.
-
-
Jedes
Element kann unter Verwendung von beschreibenden Attributen kommentiert
sein. Derartige Attribute dokumentieren das Paket und ermöglichen,
dass das Paket selbstdokumentierend ist. Durch ein Speichern der
Attribute mit der Paketdefinition und eventuell dem Paketreferenzmodell
können
die Routinen, die bereitgestellt sind, um ein Paket zu handhaben
und eine Schnittstelle mit demselben zu bilden, allgemein beschaffen
sein, z. B. ist die Datenstruktur nicht in den Routinen codiert,
stattdessen wird die Datenstruktur während der Laufzeit geliefert.
Zum Beispiel können
Attribute verwendet werden, um alle Informationen zu liefern, die
benötigt
werden, um ein beliebiges Paket unter Verwendung einer allgemeinen
graphischen Benutzerschnittstelle zu präsentieren und zu editieren.
Einige Beispiele für
mögliche
Attribute sind in Tabelle 2 gezeigt. Durchschnittsfachleute werden
erkennen, dass die Liste, die in Tabelle 2 vorliegt, nicht erschöpfend ist, sondern
dass sich andere Attribute als vorteilhaft erweisen können, abhängig von
der Implementierung der vorliegenden Erfindung.
-
-
Tabelle
3 enthält
ein Beispiel für
eine Paketdefinition in XML. Insbesondere enthält Tabelle 3 die Definition
von zwei Paketen: bgpSessionData und routePools, zusammen mit zwei
Befehlen: addIpv4RoutePool und addIpv6RoutePool. Das Paket bgp definiert
die Startdaten, die benötigt
werden, um eine bgp-Emulationssitzung zu erzeugen. Das Paket routePools
definiert einen Satz von erreichbaren Adressen, die durch ein Leitprotokoll
angezeigt werden sollen. Zwei Tabellen sind in routePools definiert:
eine für
IPv4-Adressen und eine für
IPv6-Adressen. Der Adressbereich ist parametrisch defi niert unter
Verwendung einer Startadresse, einer Präfixlänge und eines Zählwerts.
Die Befehle verweisen auf das routePools-Paket, um seinen Inhalt
zu bestücken.
Die Befehle verwenden eine ausgewählte Zeile aus einer Routepool-Tabelle als Parameter. TABELLE
3
-
Oft
müssen
Voreinstellungswerte für
Elemente eingestellt werden, die gemäß anderen Werten, die innerhalb
oder außerhalb
der Definition spezifiziert sind, variieren. In solchen Fällen kann
es von Vorteil sein, Werkzeugbefehlssprache-(TCL)Prozeduren zu integrieren,
die aufgerufen werden können,
um derartige Aufgabe auszuführen.
Eine derartige Funktion kann in der XML-Paketdefinition spezifiziert
sein. Eine Integration von TCL gehört zu den Fähigkeiten von Durchschnittsfachleuten,
und somit werden die spezifischen Details einer derartigen Integration
hier nicht erörtert.
Ein Beispiel für
einen Teil einer Paketdefinition, die TCL-Funktionen umfasst, ist in Tabelle 4
gezeigt: TABELLE
4
-
Bei
diesem Beispiel wird der Voreinstellungswert für keepalive (aktivhalten) bei
dem doppelten holdTimer (Haltezeitgeber) gehalten, unabhängig davon,
welcher Wert für
holdTimer eingestellt ist. Die TCL-Funktionen können ausgeführt werden, wenn ein Paket
instantiiert wird, z. B. eine Instanz eines Pakets erzeugt wird. Ferner
können
Routinen erzeugt werden, um während
der Laufzeit die Paketdefinition und/oder das -modell zu prüfen und
die Werte, die durch derartige Funktionen beeinflusst werden, zu
aktualisieren.
-
ARBEITEN MIT
PAKETEN
-
4 ist
ein Blockdiagramm, das die Verwendung einer Paketdefinition 202 veranschaulicht,
um ein Paketreferenzmodell 204 und ein Paketobjekt 206 gemäß einem
Ausführungsbeispiel
der vorliegenden Erfindung zu erzeugen. Allgemein dient das Referenzmodell 204 als
ein Depot für
alle Paketattribute, die Details der Datenstruktur umfassen. Bei
den beschriebenen Ausführungsbeispielen
umfassen die Strukturen hierarchische Knoten und Basistabellen,
die Erfindung ist jedoch nicht auf diese Strukturen beschränkt und
kann erweitert werden, um z. B. relationale Strukturen zu umfassen.
Zusätzlich
löst das
Referenzmodell 204 alle Querverweise in der XML zwischen
einem Paket oder Paketknoten und einem anderen.
-
5 ist
ein Flussdiagramm eines Verfahrens zum Erzeugen eines Paketobjekts
206.
Das Verfahren beginnt bei Schritt
500. Bei Schritt
502 werden
die verfügbaren
XML-Paketdefinitionsdateien
(z. B. die Paketdefinitionsdateien
206) nach <parcel> (Paket-) Tags abgetastet,
und eine Nachschlagetabelle von Tag-Namen für Dateien wird erzeugt.
-
Bei
Schritt 504 geht das Verfahren, wenn ein Paketobjekt 206 angefordert
wird, für
das kein Paketreferenzmodell 204 gebildet worden ist, zu
Schritt 506 über.
Ansonsten geht das Verfahren zu Schritt 514 über, wie
es hier im Folgenden erörtert
ist. Bei Schritt 506 wird die Nachschlagetabelle, die bei
Schritt 502 erzeugt wurde, abgetastet, um die XML-Datei zu identifizieren,
die dem angeforderten Paketobjekt 206 entspricht. Anschließend wird
bei Schritt 508 die identifizierte XML-Datei syntaktisch
analysiert, z. B. unter Verwendung einer Öffentlicher-Bereich-XML-Parser-Software,
wie z. B. expat. Der XML-Parser bzw. Analysierer erzeugt einen Vektor
von C++-Tag-Objekten, die verwendet werden, um das zugeordnete Referenzmodell 204 in
Schritt 510 zu erzeugen.
-
Mit
Bezugnahme auf das Beispiel, das in 4 gezeigt
ist, enthält
das Referenzmodell 204 einen Oberste-Ebene-Knoten, Satz
(1), der einen Tabellenknoten (2) und einen Wertknoten
(6) enthält.
Der Tabellenknoten (2) enthält drei Knoten: einen Wertknoten
(3), einen Arrayknoten (4) und einen Wertknoten
(5). Durch ein Erzeugen von drei Zeilen des Tabellenknotens
(2) werden bei dem exemplarischen Paketobjekt 206 zwölf Knoten
erzeugt.
-
Es
kann vorteilhaft sein, alle XML-Dateien zur Startzeit syntaktisch
zu analysieren, um sicherzustellen, dass alle Modelle für die gesamte
Sitzung verfügbar
sind. Dies kann sich jedoch als unnötig erweisen, da eine gegebene
Testsitzung eventuell nur einen Teilsatz von Paketen erfordert.
Deshalb kann es sich als vorteilhaft erweisen, nach Bedarf syntaktisch
zu analysieren, wie es mit Bezug auf 5 beschrieben
ist.
-
Bei
Schritt 512 wird eine Karte erzeugt und dem Referenzmodell 204 zugeordnet,
das eine Karte von Referenzpaketobjekten aufrechterhält, d. h.
Paketobjekten, die durch das Referenzmodell 204 beschrieben sind,
die per Name indexiert sind. Dies ist erwünscht, da ein einziges Referenzmodell 204 die
Beschreibung einer Mehrzahl von Referenzpaketobjekten enthalten
kann. Die Karte kann verwendet werden, um ein geeignetes Referenzmodell 204 (oder
einen Teil desselben), das das gewünschte Paket beschreibt, wiederzugewinnen,
wenn ein Paketobjekt 206 instantiiert werden soll.
-
Anschließend wird
bei Schritt 514 das Referenzmodell 204 an eine
Routine weitergegeben, die das Paketobjekt 206 erzeugt.
Auf diese Weise wird ein neues Paketobjekt 206 aus dem
zugeordneten Referenzmodell 204 erzeugt, eigentlich instantiiert.
Allgemein weist ein Paketobjekt 206 einen Kopfblock, der
das zugeordnete Referenzmodell 204 anzeigt, und eine Datenstruktur
zum Halten der Daten auf, die mit den Elementen in Beziehung stehen,
die in dem Referenzmodell 204 beschrieben sind. Wenn es
zunächst
erzeugt ist, kann die Datenstruktur, wo verfügbar, mit Voreinstellungswerten,
die in den Attributen definiert sind, bestückt werden. Wo es nötig ist,
können
Werte aktualisiert oder durch einen Benutzer oder eine andere Routine
eingegeben werden.
-
Jeder
Knoten in dem Paketobjekt 206 weist einen entsprechenden
Referenzpaketknoten auf. Das Vorliegen von Tabellen bedeutet jedoch,
dass die Entsprechung nicht unbedingt eins zu eins ist. Das liegt
daran, dass ein Paketobjekt 206 mehrere Instanzen eines
bestimmten Knotens aufweisen kann – eine für jede Zeile in der Tabelle.
Das Paketobjekt 206 muss die Attributinformationen, die
in dem Referenzmodell 204 enthalten sind, nicht umfassen
(kann jedoch). Attributinformationen können, wenn nötig, von
dem Referenzpaket 204 erhalten werden.
-
Jedem
Knoten in dem Paket einen Index zuzuweisen kann eine effiziente
Navigation zwischen Knoten des Paketobjekts 206 erleichtern.
Die Zahl in Klammern bei jedem Knoten in 4 zeigt
ein Beispiel eines Indexiersystems. Bei dem Referenzmodell 204 ist
jedem Referenzknoten ein Index zugeteilt. Jeder Referenzknoten,
der ein Behälter
ist, wie z. B. ein Satz oder eine Tabelle, kann konfiguriert sein,
um die Indizes seiner Gliedknoten aufzuzeichnen. Jeder Knoten in
einem Paketobjekt 206 bekommt den gleichen Index wie sein
entsprechender Referenzknoten 204. Ein Paketindexvektor
von aktiven Knoten in einem Paketobjekt 206 kann für eine effiziente
Navigation von Knoten in dem Objekt verwendet werden. Jeder aktive
Knoten zeichnet seinen Index in dem Vektor auf. In dem Fall von
Tabellen kann das Vorhandensein von mehreren Zeilen (und somit Knoteninstanzen)
durch ein Bezeichnen einer aktuellen (oder ausgewählten) Zeile
in der Tabelle verwaltet werden. Wenn eine Zeile ausgewählt ist,
registrieren sich die Knoten in der ausgewählten Zeile selbst mit dem Paketindexvektor.
Auf diese Weise können
nur die Knoten in der aktuellen Zeile navigiert werden – eine Zeile muss
ausgewählt
sein, bevor auf Knoten zugegriffen werden kann.
-
Um
ein Verständnis
des Prozesses zum Umwandeln einer Paketdefinition in ein Paketmodell
zu erleichtern, sind die folgenden Tabellen präsentiert. Tabelle 6 zeigt eine
Teilpaketdefinition (die drei einzelne Pakete umfasst), während Tabelle
7 ein konzeptzionelles Beispiel eines Referenzmodells ist, das auf
der Paketdefinition basiert, die in Tabelle 6 enthalten ist. TABELLE
6
TABELLE
7
-
API
-
Da
ein Paket tatsächlich
ein selbstdokumentierendes Datenmodell ist, kann eine Gruppe von
allgemeinen Routinen formuliert sein, um mit den Paketen eine Schnittstelle
zu bilden. Derartige Routinen können
hinsichtlich ihrer Funktionen als Anwendungsprogrammschnittstellen
(APIs) betrachtet werden. Es ist erwünscht, Routinen für die Erzeugung,
z. B. Instantiierung, von Paketen, das Lesen von Paketen und das
Schreiben von Paketen zu liefern. Tabelle 8 liefert Beispiele für Routinen,
die einen selbstdokumentierenden Code verwenden, die eine allgemeine
Schnittstelle mit Paketen beschreiben, einschließlich Lese- und Schreibschnittstellen. TABELLE
8
-
Es
kann bevorzugt werden, eine Reihe von Routinen für die Verwaltung von Paketen
bereitzustellen. Eine derartige Verwaltung kann durch die Client-Anwendungen,
z. B. den Host
302 und die Protokollemulatorkarte
304 in
dem in
3 gezeigten Ausführungsbeispiel, geliefert werden.
Es kann sich jedoch als vorteilhaft erweisen, eine Sammlung von
Verwaltungsroutinen bereitzustellen, die durch die Client-Anwendungen verbunden
sein können,
wobei derartige Routinen hier zusammen als Paketspeicher bezeichnet
sind. Bevorzugt wird ein Paketspeicher durch jede Softwarekomponente,
die unter Verwendung von Paketen kommuniziert, bereitgestellt. Beispielsweise
kann ein Paketspeicher zuständig
sein für:
Erzeugen von Paketen für
Clients; Codieren und Senden von Paketen zu einem Bestimmungsortpaketspeicher
(z. B. Serialisierung); Decodieren und Puffern von ankommenden Paketen
von einem anderen Paketspeicher; und Benachrichtigen der Clients, wenn
neue Paketdaten verfügbar
sind. Tabelle 9 liefert ein Muster eines selbstdokumentierten Codes
für eine Schnittstelle
zu einem Paketspeicher. Tabelle
9
-
Eine
Grundfunktion des oben beschriebenen Paketspeichers, die bei jedem
Nachrichtenübermittlungssystem
erwünscht
sein kann, ist Puffern. Im Allgemeinen bedeutet puffern das vorübergehende
Halten von Paketen, bis das empfangende (oder sendende) System bereit
ist, die Informationen, die in dem Paket enthalten sind, zu verarbeiten.
Zum Beispiel können
Pakete durch einen Client aus einem Puffer auf der Sendeseite gezogen
werden, wenn dies erforderlich ist, um eine Hostlast zu minimieren.
Alternativ dazu können Pakete
durch die Sendeseite zu einer Vielzahl von Typen von Puffern auf
der Empfangsseite geschoben werden, um eine Ansprechempfindlichkeit
zu optimieren. Der Puffertyp kann in der XML-Paketdefinition spezifiziert sein und
durch das Paketreferenzmodell bekannt gegeben werden. Alternativ
dazu könnte
der Typ basierend auf Informationen in dem serialisierten Paket
bestimmt werden. Die Anwendung kann leistungsabgestimmt sein durch
ein Einstellen der Paketpuffertypen in der XML, ohne dass die Client-Schnittstelle
beeinflusst wird oder es erforderlich ist, Software neu zu schreiben
oder neu zu kompilieren.
-
Einige
Beispiele für
geeignete Puffertypen sind in Tabelle 10 offenbart: TABELLE
10
-
Um
Bandbreite zu sparen, können
Pakete vor dem Senden serialisiert werden. Wie derselbe hier verwendet
wird, bezeich net der Begriff Serialisierung allgemein einen Prozess,
durch den Daten in einem Paket auseinandergenommen und in einer
seriellen Weise angeordnet werden, normalerweise basierend auf dem Index
jedes der Elemente. Eine minimale Menge Identifikationsmaterial
wird in dem Kopfblock des se rialisierten Pakets geliefert, um die
Wiederherstellung des Pakets am Empfangsende zu ermöglichen.
Tabelle 11 beschreibt einen möglichen
Prozess der Serialisierung für
die verschiedenen Elemente eines Pakets. TABELLE
11
-
VERSCHIEDENES
-
Obwohl
bestimmte Ausführungsbeispiele
der vorliegenden Erfindung gezeigt und beschrieben wurden, ist für Fachleute
zu erkennen, dass Veränderungen
an diesen Ausführungsbeispielen
vorgenommen werden können,
ohne von den Grundsätzen
und der Wesensart der Erfindung abzuweichen, deren Schutzbereich in
den Ansprüchen
und ihren Äquivalenten
definiert ist.
-
Zum
Beispiel besteht ein Vorteil des Verwendens einer Paketstruktur
einschließlich
Definition und Referenzmodell darin, dass die Erzeugung von Graphische-Benutzerschnittstelle-(GUI)Elementen
automatisiert werden kann. In anderen Worten kann der Inhalt eines
Pakets unter Verwendung eines Formats angezeigt werden, das basierend
auf dem Paket selbst abgeleitet ist. Durch ein syntaktisches Analysieren
der Paketdefinition oder des Referenzmodells kann eine Schnittstelle
während
des Betriebs hergestellt werden. Eine derartige Schnittstelle kann
zum Betrachten des Inhalts eines Pakets oder zur Paketerzeugung
und -editierung verwendet werden.
-
6 zeigt
eine Schnittstelle, die basierend auf der Tabellenstruktur erzeugt
ist, die in der Paketdefinition definiert ist, die in Tabelle 13
enthalten ist. TABELLE
13
-
7 zeigt
eine Schnittstelle, die basierend auf den Sätzen von Werten erzeugt ist,
die in der Paketdefinition definiert sind, die in Tabelle 14 enthalten
ist. In
7 ist eine Baumstruktur ausgewählt, um
die hierarchische Beschaffenheit der in der Definition beschriebenen
Daten zu betonen. TABELLE
14
-
Ein
weiteres Beispiel für
Veränderungen,
die an diesen Ausführungsbeispielen
vorgenommen werden können,
ohne von den Grundsätzen
und der Wesensart der Erfindung abzuweichen, ist die Bereitstellung
einer Einrichtung, um iterativ Paketinstanzen zu erzeugen. Sollte
z. B. eine Reihe von Paketen erwünscht
sein, wobei sich ein oder mehr Werte unter Paketen unterscheiden,
kann eine iterative Funktion bereitgestellt sein, die diese Paketwerte
in relativer Form definiert, wie z. B. +1. Auf diese Weise kann
ein einzelnes Paket verwendet werden, um parametrisch durch die
Verwendung von Paketiteration viele unterschiedliche Pakete zu erzeugen.
Wird das Beispiel einer Protokollemulationsanwendung verwendet,
kann es erwünscht
sein, einen Sitzungspool von vielen Sitzungen zu erzeugen, der unter
Verwendung der Pakete nur einer Sitzung definiert ist. Dies kann
implementiert sein durch ein Etikettieren bestimmter Werte in dem
XML-Modell mit Voreinstellungsinkrementattributen. Das In krement
wird verwendet, um jeden Wert für
jede Iteration des Pakets einzustellen. Zum Beispiel kann ein Wert
ein Voreinstellungsinkrement von „10" spezifizieren. Falls der Wert bei dem
ersten Paket 50 beträgt,
beträgt
der Wert, wenn das Paket einmal iterativ wiederholt wird, 60. Falls
das Paket zweimal iterativ wiederholt wird, beträgt der Wert 70. Das Voreinstellungsinkrement
kann auch durch eine Inkrementierfunktion berechnet werden. Dies
ermöglicht,
dass der Voreinstellungsinkrementwert basierend auf anderen Werten
in dem Paket intelligent zugewiesen wird.
