-
Netzwerkvorrichtungen,
z.B. Router, werden umfassend getestet, um zu gewährleisten,
dass Fehlübertragungen
und fatale Fehler minimiert werden. Auf dem Markt sind eine Vielzahl
von Testvorrichtungen 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 Routens kann rasch so zusammengefasst werden, dass ein
Knoten den Pfad zu jedem möglichen
Zielort findet. Ein Routen liegt überall von der Schicht 1 (der
physischen Schicht) nach oben vor. Das Routen, das die meisten Leute
kennen, erfolgt jedoch auf der Schicht 3 (auf der Netzwerkschicht), und
als solches wird hierin lediglich auf ein Schicht-3- (und im Einzelnen)
Internet-Protokoll-Routen (Schicht-3-IP-Routen)
Bezug genommen. Router verwenden Tabellen, um zu bestimmen, wo Pakete
hingeleitet werden sollen. Ein Aktualisieren dieser Tabellen ist
eine Funktion, die durch Routing-Protokolle erfüllt wird.
-
Routing-Protokolle
ermöglichen
ein Austauschen von Routing-Informationen
zwischen Routern auf der ganzen Welt, die durch heterogene, jedoch
allgemein übereinstimmende
Routing-Tabellen jedes Routers eine gemeinsame Ansicht des Netzwerks
liefern. Routing-Tabellen speichern alle Informationen, die für den Router
notwendig sind, um jeden Zielort in dem Netzwerk ungeachtet der
Größe zu erreichen.
Es gibt eine große
Vielfalt von Routing-Protokollen, die verwendet werden, um Informationen
für Routing-Tabellen über ein Netzwerk
zu verteilen, einschließlich:
BGP; OSPF; RIP und ISIS. Im Rahmen eines Versuchs, die Leistungsfähigkeit
von Routern zu verbessern, werden alte Protokolle oft erwei tert,
und es werden ständig
neue Protokolle erstellt. Üblicherweise
werden neue Protokolle anfänglich
durch Ausrüstungshersteller
entwickelt und sind gesetzlich geschützt. Oft übernehmen Standardkörperschaften
in der Industrie anschließend
die Protokolle.
-
Bekannte
Routertester simulieren einen Netzwerkverkehr, wobei sie speziell
erstellte „Testpakete" von Daten verwenden,
die für
die in dem Netzwerk vorhandenen heißen Daten typisch sind. Diese
Testpakete werden über
ein zu testendes Netzwerk an die Netzwerkvorrichtung gesendet. Parameter,
die durch Verkehrssimulatorsysteme, einschließlich ROUTER TESTER) getestet
werden, umfassen eine Routing-Überprüfung, ein Erreichen
von Dienstgüte-Niveaus
(QoS-Niveaus, QoS = Quality of Service) bei Belastung sowie eine
korrekte Zusammenarbeit mit anderen Vorrichtungen. Viele dieser
so genannten „Paketladeprogramme" testen ferner die
Fähigkeit
der Netzwerkvorrichtung, sich an Protokolle zu halten, indem sie
Mitteilungen gemäß den Protokollen
formulieren und senden. Derartige Mitteilungen sind als Protokollmitteilungen
bekannt.
-
1 ist ein Blockdiagramm
eines Verkehrssimulatortestsystems 100. Insbesondere ist
das Verkehrssimulatortestsystem 100 eine allgemeine Darstellung
von ROUTER TESTER, der von AGILENT TECHNOLOGIES angeboten wird.
ROUTER TESTER ist lediglich ein Beispiel eines Routertestsystems
und wird insbesondere als Mehrtorverkehrserzeugungs-, Protokollemulations-
und Analysetestsystem zum Überprüfen der
Leistungsfähigkeit
von Unternehmens-, Metro/Edge-, Kern-Routing- und optischen Vernetzungsvorrichtungen
beworben. Das System umfasst allgemein eine Mehrzahl von Protokollemulationskarten 102n,
die mit einem zu testenden System, in diesem Fall einem Router 104,
verbunden sind. Jede der Protokollemulationskarten 102n umfasst
allgemein einen Prozessor mit einem zugeordneten Speicher und I/O
(Eingang/Ausgang). Ein Computer 106, wie z.B. ein PC, der
in einer WINDOWS-Umgebung läuft,
steuert die Protokollemulati onskarten 102n. Der Computer 106 spricht
auf eine Schnittstelle 108, z.B. eine graphische Benutzerschnittstelle,
an.
-
Die
durch die Protokollemulationskarten 102n erzeugten Testpakete
und Protokollmitteilungen werden gemäß den Regeln und Interpretationen
von Kommunikationsprotokollen, z.B. denjenigen, die durch die vielen Standardkörperschaften
in der Industrie definiert werden, erstellt. Allgemein werden die
meisten der Protokollmitteilungen, die einem beliebigen gegebenen
Protokoll zugeordnet sind, beim Vorgang des Quittungsbetriebs (Handshaking)
verwendet. Da der Quittungsbetriebsprozess sich für definierte
Zustände
eignet, verwenden die meisten Router und Protokollemulatoren eine
Finit-Zustands-Maschine, um auf die verschiedenen Protokollmitteilungen
zu antworten.
-
Die
aktuelle Softwarearchitektur, die Verkehrssimulatortestsystemen
zugeordnet ist, erfordert ein Festcodieren aller Teile der Protokollemulationslösung, einschließlich der
graphischen Benutzerschnittstelle, einer Skript-API, Konfigurations-
und Steuerkomponenten und der Protokollzustandsmaschine selbst.
Das für
jedes Protokoll erforderliche Festcodieren führte zum Einsatz von enorm
viel menschlichem Talent, um den großen Codeblock zu erstellen.
-
Mit
zunehmender Einführungsgeschwindigkeit
für neue
Protokolle und Erweiterungen derselben wird eine rechtzeitige Lieferung
von Testfolgen immer schwieriger. Jede neue Variation oder Hinzufügung zu
einer Protokollemulation erfordert die Modifikation eines Quellencodes
und eine anschließende
Neukompilierung. Kunden von Protokolltestern fragen bereits nach
der Fähigkeit,
die Protokollemulation zu modifizieren, oft um ein Testen eines
nicht freigegebenen Protokolls oder einer nicht freigegebenen Erweiterung
zu ermöglichen. Damit
sie durchführbar
ist, sollte eine derartige Modifikation keine Neukompilierung des
Systems erfordern.
-
Manche
erhältliche
Protokollemulatoren ermöglichen
eine gewisse Zweckanpassung durch die Verwendung von benutzerdefinierten
Objekten, die zu einer Protokollmitteilung hinzugefügt werden
können.
Jedoch erfolgt eine derartige Zweckanpassung in Form von Hexcodes,
die erfordern, dass der Benutzer mit den manchmal geheimnisvollen
Codes vertraut ist. Ferner sind die so definierten Objekte insofern
statisch, als sie nicht in der Lage sind, sich während des Vorgangs des Stimulierens
des Netzwerks zu verändern.
Die Objekte sind darauf beschränkt,
Erweiterungen einer Hauptprotokollmitteilung zu sein, was bedeutet,
dass der Hauptteil der Mitteilung unveränderlich ist.
-
Derzeit
werden Anstrengungen unternommen, generische Systeme zu entwerfen,
die außerhalb
der Software konfiguriert sein können.
Ein Beispiel ist in der gleichzeitig anhängigen US-Patentanmeldung Seriennummer:
10/266,507, Veröffentlichungsnummer:
US20040068681 A1 mit dem Titel Building packets of data beschrieben.
Die US20040068681 A1 ist durch Bezugnahme in das vorliegende Dokument
aufgenommen und verwendet eine externe XML-Protokollbeschreibung,
um eine generische PDU-Codierungs-/Decodierungsmaschine zu treiben,.
-
Demgemäß erkannten
die Erfinder der vorliegenden Erfindung einen Bedarf an neuen Vorrichtungen und
Verfahren, die einen Benutzer befähigen, einer Protokollemulationsfolge
eine neue Fähigkeit
hinzuzufügen,
ohne dass eine Neukompilierung erforderlich ist, und die den Benutzern
als nahtloser Bestandteil des Systems erscheinen.
-
Bevorzugte
Ausführungsbeispiele
der vorliegenden Erfindung werden nachfolgend Bezug nehmend auf
die beiliegenden Zeichnungen näher
erläutert.
Es zeigen:
-
1 ein
Blockdiagramm eines Protokollemulationstestsystems;
-
2 ein
Blockdiagramm einer Architektur zum Erstellen von Protokollmitteilungen
gemäß einem
bevorzugten Ausführungsbeispiel
der vorliegenden Erfindung;
-
3 einen
Screenshot einer graphischen Benutzerschnittstelle, die gemäß einem
Ausführungsbeispiel
der vorliegenden Erfindung aufgebaut ist.
-
In
der hiernach folgenden Beschreibung bezeichnet die Verwendung eines
kleinen „n", das neben einem
Elementidentifizierer steht, eine nicht-spezifische Instanz des
Elements und nicht ein spezifisches Element, wie in der Spezifikation
unter Verwendung eines nicht in Kursivschrift geschriebenen Buchstabens
neben der Elementzahl erörtert
wird, oder die allgemeine Sammlung aller Instanzen, wie unter Verwendung
der Elementzahl alleine mit einem Modifizierer erörtert wird.
-
Im
Folgenden wird auf Ausführungsbeispiele
der vorliegenden Erfindung Bezug genommen, von denen Beispiele in
den beiliegenden Zeichnungen veranschaulicht sind, bei denen sich
gleiche Bezugszeichen durchwegs auf gleiche Elemente beziehen. Die
folgende ausführliche
Beschreibung stellt Verfahren vor, die durch Routinen und symbolische
Darstellungen von Vorgängen
von Datenbits in einem computerlesbaren Medium, zugeordneten Prozessoren,
Datenerzeugungs- und Erfassungskarten und dergleichen verkörpert sein können. Als
Routine versteht man hier und im Allgemeinen eine Sequenz von Schritten
oder Handlungen, die zu einem gewünschten Ergebnis führt, und
als solches umfasst der Begriff Routine Fachbegriffe wie „Programm", „Ziele", „Funktionen", „Teilroutinen" und „Prozeduren". Diese Beschreibungen
und Darstellungen sind die Mittel, die von Fachleuten verwendet
werden, um die Essenz ihrer Arbeit anderen Fachleuten effektiv zu vermitteln.
Der Zweckmäßigkeit
halber wird das Wort „Netzwerk" hiernach in der
Beschreibung und in den Patentansprüchen dazu verwendet, auf eine(s)
oder mehrere der folgenden Bezug zu nehmen: ein Kommunikationsnetzwerk,
eine Netzwerkvorrichtung oder eine andere Kommunikationsvorrichtung
und einen beliebigen Aspekt oder beliebige Aspekte eines Kommunikationssystems,
das unter Verwendung von Testdatenpaketen getestet werden kann.
-
Ausführungsbeispiele,
die Verfahren umfassen, werden bezüglich einer Implementierung
an einen Routertester beschrieben, dessen Konfiguration ähnlich der
des ROUTER TESTER von AGILENT ist; die hierin aufgeführten Verfahren
arbeiten jedoch eventuell bei einer Vielzahl von Routertestern.
Genauer gesagt sind die hierin vorgestellten Verfahren nicht inhärent auf
eine bestimmte Vorrichtung bezogen; vielmehr können bei Routinen gemäß den hierin
offenbarten Lehren verschiedene Vorrichtungen verwendet werden.
Insbesondere sind die hierin für
einen Datentransfer von einer Vorrichtung zu einer anderen beschriebenen
Verfahren eventuell auf das Gebiet der Datenkommunikation im Allgemeinen
anwendbar, auch wenn sie unter Bezugnahme auf eine Routertesterfunktion
beschrieben wurden. Maschinen, die die hierin beschriebenen Funktionen
erfüllen
können,
umfassen diejenigen, die von Unternehmen wie z.B. AGILENT TECHNOLOGIES,
INC., HEWLETT PACKARD, und TEKTRONIX, INC. sowie anderen Herstellern
von Kommunikationseinrichtungen hergestellt werden.
-
Bezüglich der
hierin beschriebenen Software werden Fachleute erkennen, dass es
eine Vielzahl von Plattformen und Sprachen zum Erzeugen einer Software
zum Ausführen
der hierin umrissenen Prozeduren gibt. Ausführungsbeispiele der vorliegenden
Erfindung können
unter Verwendung einer beliebigen Anzahl von Abwandlungen von C,
einschließlich
C++, implementiert werden. Jedoch werden
Fachleute ebenfalls erkennen, dass die Auswahl der genauen Plattform
und Sprache oft durch die Besonderheit des erstellten tatsächlichen Systems
vorgegeben wird, so dass das, was für eine Art System funktionieren
mag, bei einem anderen System eventuell nicht effizient ist. Ferner
sollte man verstehen, dass die hierin beschriebenen Routinen und
Berechnungen nicht darauf beschränkt
sind, als Software an einem Computer ausgeführt zu werden, sondern auch in
einem Hardwareprozessor implementiert sein können. Beispielsweise könnten die
Routinen und Berechnungen unter Verwendung einer Vielzahl von Entwurfshilfsmitteln
mit HDL (Hardware Design Language, Hardware-Entwurfssprache) in
einer ASIC oder in einer FGPA implementiert werden.
-
Anmelder
stellten fest, dass sich bestimmte Teile einer Protokollemulation
dazu eignen, auf generische Weise definiert zu werden, während andere
Komponenten aus Skalierbarkeits- und Leistungsfähigkeitsgründen eventuell geeigneter dafür sind,
festcodiert zu werden. Indem eine vor Ort erfolgende Kundenspezifikation derjenigen
Abschnitte ermöglicht
wird, die auf generische Weise definiert werden können, gibt
man dem Kunden eine zusätzliche
Kontrolle über
die Protokollemulation und die Fähigkeit,
die Tests zu erweitern. Um eine Kundeninteraktion zu ermöglichen,
können
die generisch definierten Abschnitte in einem leicht lesbaren Dateiformat,
z.B. XML, dargestellt werden. Eine derartige XML-Datei kann verwendet
werden, um eine graphische Schnittstelle zu bilden, durch die eine
Modifikation der in der XML beschriebenen Informationen eingesehen
werden kann. Diese Informationen würden verwendet, um eine Definition
zu erstellen, die für
eine Finit-Zustands-Maschine einer bestimmten Protokollemulation
verständlich
ist.
-
2 ist
ein Blockdiagramm eines Protokollemulationssystems 200 zum
Erstellen von Protokollmitteilungen gemäß einem bevorzugten Ausführungsbeispiel
der vorliegenden Erfindung. Die Architektur 200 umfasst
allgemein einen Host 202 und einen Protokollemulator 204.
Der Host 202 ist üblicherweise
als Computer verkörpert,
der zusammen mit Anwendungen 208 auf eine graphische Benutzerschnittstelle 206 anspricht.
Obwohl in 2 eine Mehrzahl von Anwendungen 208n gezeigt
ist, sollte man beachten, dass die Anwendungen 208n je
nach der genauen Implementierung der vorliegenden Erfindung physikalisch
oder logisch als einzelne Anwendung oder als beliebige Anzahl von
Anwendungen implementiert sein könnten.
Der Protokollemulator 204 umfasst allgemein eine Protokoll-Finit-Zustands-Maschine 210,
die auf zumindest eine Schablone 212 zum Erzeugen von Protokollmitteilungen
anspricht. Der Computer 202 fungiert allgemein als Client,
der Anweisungen an den Protokollemulator 204 liefert, der
allgemein als Server fungiert, der auf die Anweisungen des Computers 202 anspricht.
-
Protokollmitteilungsbeschreibungen 215,
die entweder vor Ort bei dem Host 202 oder an einer entfernten
Stelle gespeichert sein können,
enthalten zumindest eine Beschreibung 215n aller oder mancher
der Felder und Feldbeziehungen für
ausgewählte
Protokollmitteilungstypen und die damit verbundenen Protokollparameteroptionen.
Eine Protokollmitteilungsbeschreibung 215n stellt eine
ganze Protokolldateneinheit oder ein Fragment derselben in einem
generischen Format dar (z.B. variiert das Format der eingereichten
Beschreibung 215 nicht von Protokoll zu Protokoll). Beispiele
von Mitteilungen, für
die sich Protokollmitteilungsbeschreibungen 215 als nützlich erweisen
können,
umfassen folgende: BGP4 Upate Message; OSPF Link State Update Packet;
ISIS Link State Packet; RIP Update Message; LDP Label Mapping Message;
LDP Label Request Message; RSVP Path Message; PIM Join oder Register
Message; und IGMP Membership Reports.
-
Eine
Protokollmitteilungsbeschreibung 215n für ein gegebenes Protokoll kann
mit einem Protokolldeskriptor mit allgemeinen Attributen beginnen,
die sich auf das Protokoll beziehen, gefolgt von einer Anzahl von Felddeskriptoren,
von denen jeder Felder beschreibt, die in einer gemäß dem Protokoll
erstellten Mitteilung vorliegen können. Die Felddeskriptoren
können
eine Vielzahl von Attributinformationen enthalten.
-
Beispielsweise
kann ein vollständiger
Name zur Anzeige mit den Werten, die dem Feld zugeordnet sind, spezifiziert
werden. Was den Wert selbst betrifft, können Attribute wie z.B. Länge, Format
und Anfangswert bereitgestellt werden. Um die Nützlichkeit der Protokollmitteilungsbeschreibungen 215 weiter
zu erhöhen, können Anweisungen
bezüglich
dessen geliefert werden, wie der Wert eines Feldes von Kopie zu
Kopie einer Mitteilung (die gemäß den Protokollmitteilungsbeschreibungen 215 erstellt
ist) variiert werden kann. Im Fall von Feldern, die innerhalb einer
spezifischen Mitteilung wiederholt werden, kann eine Anweisung bezüglich dessen
bereitgestellt werden, wie der Wert des Feldes von Fall zu Fall
variiert werden kann. Beispielsweise kann ein inkrementeller Wert
bereitgestellt werden, um den IP-Wert-Präfix
bei jedem einer Serie von Netzwerkerreichbarkeitsindikatoren anzupassen.
-
Wenn
XML als die Beschreibungssprache verwendet wird, können die
Deskriptoren durch Markierungen verkörpert sein, die auf bekannte
Weise verschachtelt sein können,
um eine hierarchische Struktur zu liefern. Eine derartige hierarchische
Struktur ermöglicht
die dynamische Erzeugung einer graphischen Benutzerschnittstelle,
die eine rasche und problemlose Navigation durch die Datenstruktur
bietet.
-
Die
Protokollmitteilungsbeschreibungen
215 können gemäß der allgemeinen
Lehre der US-Patentanmeldung 10/266,507 (als US 2004/0068681 A1
veröffentlicht),
die durch Bezugnahme in das vorliegende Dokument aufgenommen ist,
gebildet werden. Tabelle 1 enthält
ein Beispiel einer Protokolldefinition für eine BGP4-Aktualisierungsmitteilung.
Die in Tabelle 1 gezeigte Datenstruktur liefert ein Beispiel einer
Protokollmitteilungsbeschreibung
215n, wie sie in XML verkörpert ist
und der Fachleute eine Struktur und einen Zweck entnehmen können, um
die Erstellung anderer Protokolldefinitionen für andere Mitteilungen und andere
Protokolle zu ermöglichen. TABELLE
1
-
Um
neue Protokollemulationen zu erzeugen, gewinnt eine Anwendung 208n die
benötigte(n)
Protokollmitteilungsbeschreibung(en) 215n und lädt sie in
ein Protokollreferenzmodell 214. Das Referenzmodell 214 umfasst
allgemein eine Datenstruktur, z.B. ein Objekt, die die in allen
ausgewählten
Protokollmitteilungsbeschreibungen 215n enthaltenen Felder
beschreibt. Das Modell kann konstruiert werden, indem jede Protokollmitteilungsbeschreibung 215n unter
Verwendung z.B. einer Öffentliche-Domain-XML-Parsersoftware,
z.B. Expat, geparst wird. Nachdem das Protokollreferenzmodell 214 konstruiert
wurde, kann eine Instanz 216n desselben instantiiert und
mit durch einen Benutzer bezeichneten Werten und Anweisungen besetzt
werden.
-
Um
die durch eine Instanz 216n gespeicherten Werte zu editieren,
wird die Instanz 216n an die GUI 206 weitergeleitet.
Alternativ dazu kann die GUI 206 die Instantiierung einer
Instanz 216n anfordern. In jedem Fall bildet die GUI 206 eine
graphische Anzeige auf der Basis ausgewählter Felder in dem Protokollreferenzmodell 214,
einer Protokollmitteilungsbeschreibung 215n oder einer
Instanz 216n. Bei dem vielleicht bevorzugten Ausführungsbeispiel
erstellt und besetzt die GUI 206 einen Baum, der die durch
die Protokollmitteilungsbeschreibungen 215 dargestellte
verschachtelte Datenstruktur nachahmt.
-
3 ist
ein Screenshot einer graphischen Benutzerschnittstelle 206,
die gemäß einem
Ausführungsbeispiel
der vorliegenden Erfindung erstellt wurde. Um eine Anzeige, z.B.
die in 3 gezeigte, zu erzeugen, wird der Inhalt z.B.
des Protokollreferenzmodells 214 analysiert, um die Felder
zur Anzeige und das Format derselben zu identifizieren. Bei dem
in 3 gezeigten Beispiel wird eine hierarchische Datenstruktur
erstellt und mit einem Eintrags- oder Anzeigefeld besetzt, wobei
jedes Feld ein Knoten in dem Baum ist. Die sich ergebende Baumstruktur
kann anschließend
in einer herkömmlichen
hierarchischen Anzeige dargestellt werden, bei der Datenknoten auf
Grund ihrer Deskriptoren formatiert werden.
-
Bei
dem in 3 gezeigten Beispiel ist es dem Benutzer erlaubt,
bestimmte Attribute der angezeigten Felder anzupassen, einschließlich des
Startwerts, des Endwerts, des Zählwerts
und des Schrittes, der eine Steuerung auf einer Feld-Um-Feld-Basis
auf der Grundlage des Inhalts der Protokollmitteilungsbeschreibung 215n (oder,
richtiger, der Instanz 216n) ermöglicht. Beispielsweise kann
ein Attribut hinzugefügt
werden, um anzumerken, dass der Wert des Feldes feststehend ist
(oder von einem anderen Feld abhängig
ist). Nachdem der Benutzer die Knoten überprüft und die ihm zur Verfügung stehenden
Knoten angepasst hat, leitet die graphische Benutzerschnittstelle 206 die
angepasste Instanz 216n zurück an eine Anwendung 208n.
Eine Anwendung 208n erstellt anschließend auf der Grundlage der
angepassten Instanz 216n eine Schablone 212n.
-
Eine
Schablone
212 ist ein Satz von Anweisungen an die Protokoll-Finit-Zustands-Maschine
210 bezüglich der
Erstellung von Protokollmitteilungen. Es kann vorteilhaft sein,
ein binäres
(oder sedezimales) Format für
die Schablonen
212 zu verwenden, so dass sie der durch
die Protokoll-Finit-Zustands-Maschine
210 verwendete,
derzeit festcodierten Anweisung entsprechen. Auf diese Weise sollten
derzeitige Protokoll-Finit-Zustands-Maschinen nur geringfügige Modifikationen
erfordern, um mit Schablonen
212 zu interagieren. Unter
Bezugnahme auf
2 können entweder die graphische
Benutzerschnittstelle
206 oder Anwendungen
208n konstruiert
sein, um als Compiler von Protokollmitteilungsbeschreibungen
215 zu
agieren. Schablonen
212 weisen allgemein drei Segmente
auf, wie in Tabelle 2 gezeigt ist: TABELLE
2
-
Schablonen 212 umfassen
allgemein einen ersten Teil (als gemeinsamer Teil bezeichnet) von
sich nicht wiederholenden Daten und einen zweiten Teil (als Wiederholungsteil
bezeichnet) von sich wiederholenden Abschnitten mit auf ähnliche
Weise formatierten Daten unterschiedlicher Werte. Jede Schablone 212n stellt
eine Basismitteilungsbeschreibung dar, von der viele Mitteilungen
erzeugt werden können.
Jede Schablone 212n weist einen gemeinsamen Teil auf und
kann einen Wiederholungsteil aufweisen. Der Wiederholungsteil kann
viele Felder aufweisen, die über
eine Sequenz erstellter Mitteilungen hinweg variieren. Der gemeinsame
Teil stellt üblicherweise
den Mitteilungskopf und gemeinsame Attribute für die Topologiedaten dar. Beim
BGP-Protokoll kann der gemeinsame Teil einer Aktualisierungsmitteilung
den Mitteilungskopf und Pfadattribute umfassen. Der Wiederholungsteil
beschreibt einen Satz von Feldern, die innerhalb einer einzigen Mitteilung
mehrmals wiederholt werden sollen. Mit jeder Wiederholung kann bzw.
können
eines oder mehrere der Wiederholungsfelder auf definierte Weise
variieren. Der Wiederholungsteil stellt allgemein Netzwerktopologiedaten
dar. Beim BGP-Protokoll kann der Wiederholungsteil die vielen tausend
Netzwerkpräfixe,
für die
geworben werden soll, umfassen.
-
Unter
erneuter Bezugnahme auf 2 ist jede Instanz 216 als
Vektor von Protokollelementen gespeichert. Durch Codieren von Byte-Zeichenfolgen
des Vektors kann eine Schablone 212 gebildet werden. Die Byte-Zeichenfolge
kann codiert werden, indem der binäre Wert jedes aktivierten Feldes
in dem Vektor von Protokollelementen verkettet wird. Es kann sich
als vorteilhaft erweisen, sowohl die Vektordarstellung als auch
die codierte Darstellung zu speichern. In einem solchen Fall wird,
wenn die GUI 206 eine Instanz 216 durch Manipulieren
eines Elements in dem Vektor aktualisiert (d.h. Wert geändert, Feld
aktiviert oder deaktiviert), die entsprechende Byte-Zeichenfolge
aktualisiert. Ein Feldmodifizierer kann auf jegliches Element in
dem Vektor angewendet werden; der Feldmodifizierer kann relativ
zu der Byte-Zeichenfolge
als Versatz, Feldbreite, Startwert, Inkrement und Zählwert codiert
sein. Eine Schablone 212 umfasst allgemein einen Satz von
Feldmodifizierern, die die codierten Byte-Zeichenfolgen begleiten.
-
Ein
optionales Merkmal, das implementiert werden kann, ist die Verwendung
eines Flags (oder einer anderen Datenstruktur), um anzugeben, ob
eine Schablone während
einer beliebigen Sitzung verwendet werden soll. Wenn also das Flag
für eine
gegebene Schablone 212n gesetzt ist, wird diese Schablone 212n durch die
Protokoll-Finit-Zustands-Maschine 210 verwendet, um Mitteilungen
zu erzeugen. Das Flag kann ein Bestandteil der Schablone sein oder
andernorts aufbewahrt werden, z.B, als Bestandteil eines Registers
oder einer Tabelle.
-
Während des
Betriebs führt
die Protokoll-Finit-Zustands-Maschine 210 einen
anfänglichen
Handshake-Vorgang durch. An dem entsprechenden Punkt greift die
Protokoll-Finit-Zustands-Maschine 210 auf
verfügbare
Schablonen zu (die auf diejenigen mit einem EIN-Flag beschränkt sind,
falls eine derartige Option erwünscht
ist) und beginnt auf der Basis der Schablonen Mitteilungen zu erstellen.
-
Die
Protokollmitteilungsbeschreibungen 215 eignen sich ferner
zur Verwendung als Filter. Benutzer von Protokollemulationssystemen,
z.B. des Systems 200, möchten
allgemein einen an das System gesendeten Verkehr überprüfen. Jedoch
ist der Umfang eines derartigen Verkehrs tendenziell ziemlich groß, so dass ein
Durchsortieren des Verkehrs nach interessierenden Mitteilungen oder
Abschnitten von Mitteilungen mühselig
sein kann. Ein Vorteil der Verwendung von Protokollmitteilungsbeschreibungen 215 besteht
darin, dass sie eine hervorragende Grundlage für Filterdefinitionen bilden,
die auf die ankommenden Mitteilungsströme angewendet werden können, um
interessierende Mitteilungen oder Abschnitte von Mitteilungen zu
identifizieren.
-
Gemäß einem
Ausführungsbeispiel
der vorliegenden Erfindung werden Protokollmitteilungsbeschreibungen 215 zum
Bilden von Filtern 217 verwendet. Zur Erstellung eines
Filters können
eine Vielzahl von Verfahren verwendet werden. Bei dem vielleicht
bevorzugten Ausführungsbeispiel
werden ausgewählte
Protokollmitteilungsbeschreibungen 215n in das Protokollreferenzmodell 214 geladen
und über
die GUI 206 dem Benutzer zur Modifikation präsentiert.
Der Benutzer liefert Werte für
jedes der verfügbaren
Felder, auf dem eine Mitteilung gefiltert werden soll. Derartige
Werte kann man entweder als Hineinfiltern der Mitteilung (z.B. soll
die Mitteilung gesichert werden) oder als Herausfiltern der Mitteilung
(z.B. soll die Mitteilung verworfen werden) bezeichnen. Die Filter 217 können strukturiert
sein, um Abschnitte (oder „Fragmente") von Mitteilungen
zu identifizieren, die in dem Fall, dass die Mitteilung eingefiltert
wird, zu sichern sind. Wie in dem Fall der Schablonen 212 erzeugt
die GUI 206 oder eine Anwendung 208n ein Filter 217n auf
der Basis der bereitgestellten Daten (zusammen mit der Protokollmitteilungsbeschreibung 215)
und sendet das Filter 217n zur Speicherung an den Protokollemulator 204.
Es kann jeglicher verfügbare
Filteralgorithmus verwendet werden, derart, dass die tatsächliche
Struktur der Filter 216 je nach der Implementierung des
Protokollemulators und des ausgewählten Filteralgorithmus variieren
kann.
-
Während des
Betriebs werden die Filter 216 an Daten angelegt, die bei
der Protokoll-Finit-Zustands-Maschine 210 ankommen. Mitteilungen,
oder Fragmente derselben, die eingefiltert werden, werden in einer
Fragmenterfassungsdatenbank 218 gespeichert. Die Fragmenterfassungsdatenbank 218 kann
sich entweder entfernt von dem oder an dem Protokollemulator 204 befinden.
-
Die
Fragmenterfassungsdatenbank 218 speichert erfasste Daten
als Reihe von erfassten Aufzeichnungen in einem maschinenlesbaren
Format. Die Datenbank 218 enthält eventuell lediglich einen
einzigen Fragmenttyp oder eine Vielzahl von Fragmenttypen, mit zugeordneten
Fragmenttypdeskriptoren: Um die Fragmente in einer für Menschen
lesbaren Form zu präsentieren,
verwendet eine Anwendung 208n das Protokollreferenzmodell 214,
um binäre
Daten eines Fragments zu einem Satz von Feldbeschreibungen, Werten
und Formatierungsregeln zu decodieren. Die GUI 206 präsentiert
dem Benutzer den Inhalt der Fragmente in einer graphischen Form.
Alternativ dazu kann eine Anwendungsprogrammierungsschnittstelle
(„api
- application programming interface") eingerichtet werden, um einen Zugriff
auf die Datenbank 218 von jeglicher Anwendung zu ermöglichen.
-
Obwohl
bestimmte Ausführungsbeispiele
der vorliegenden Erfindung gezeigt und beschrieben wurden, werden
Fachleute erkennen, dass an diesen Ausführungsbeispielen Änderungen
vorgenommen werden können,
ohne von den Prinzipien und der Wesensart der Erfindung, deren Schutzumfang
in den Patentansprüchen
und ihren Äquivalenten
definiert ist, abzuweichen.
-
Beispielsweise
erleichtert die Verwendung von Protokollmitteilungsbeschreibungen
215 die
Erweiterung definierter Pro tokollemulationen.
3 stellt
die in Tabelle 2 definierte Felddefinition mit Erweiterungen für Multicast
IPv6 dar. TABELLE
3
-
Da
die GUI 206 eventuell programmiert wird, um auf der Basis
einer Protokollmitteilungsbeschreibung 215 auf dynamische
Weise eine graphische Anzeige zu erzeugen, ist für die Erzeugung einer Benutzerschnittstelle
bezüglich
einer neu definierten Protokollmitteilungsbeschreibung 215n keine
zusätzliche
Programmierung erforderlich. Wenn man ferner annimmt, dass jeglicher
Vervielfältigungsvorgang,
der in der neuen Protokollmitteilungsbeschreibung 215n definiert
ist, in der Software definiert wurde, die Protokollmitteilungsbeschreibungen 215 in
Schablonen 212 umwandelt, muss in der Protokoll-Finit-Zustands-Maschine 210 keine neue
Codierung vorgenommen werden.
