DE112004000122T5

DE112004000122T5 - Vorrichtung und Verfahren zum Konfigurieren des Datenebenenverhaltens auf Netzwerkweiterleitungselementen

Info

Publication number: DE112004000122T5
Application number: DE112004000122T
Authority: DE
Inventors: Shriharsha Hedge; Russell Fenger; Amol Kulkarni; Hsin-Yuo Liu; Hormuzd Khosravi; Manasi Deval
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2003-01-07
Filing date: 2004-01-02
Publication date: 2013-01-17
Also published as: GB0513407D0; WO2004064309A2; US7646759B2; GB2413032B; GB2413032A; JP2006515499A; JP5160214B2; KR20050095841A; JP2008125116A; CN1723439A; CN100401254C; US20040131079A1; KR100747181B1; WO2004064309A3

Abstract

Es werden ein Verfahren und eine Einrichtung zum Konfigurieren des Datenebenenverhaltens auf Netzwerkweiterleitungselementen beschrieben. In einer Ausführungsform beinhaltet das Verfahren den Empfang von einer Protokollanwendung entnommenen Protokollkonfigurationsinformation innerhalb einer Netzwerkelement-Steuerebene, wobei eine Programmierschnittstelle (API) der Netzwerkprotokoll-anwendung zum Einsatz kommt. Nach Empfang der Protokoll-konfigurationsinformation wird diese unter Einsatz einer Steuerschnittstelle verarbeitet, wobei eine Steuerschnittstelle verwendet wird, die dem von der Protokollanwendung implementierten Netzwerkprotokoll entspricht. Nach Verarbeitung der Protokoll-konfigurationsinformation programmiert die Steuerschnittstelle eine oder mehrere Datenebenen-Weiterleitungselemente des Netzwerkelements gemäß der Protokollkonfigurationsinformation. Durch diese Vorgehensweisetellen für verschiedene Netzwerkprotokolle die Zusammenarbeit von Bauteilen verschiedener Lieferanten ermöglicht.

Description

ERFINDUNGSGEBIET
Eine oder mehrere Ausführungsformen der Erfindung beziehen sich allgemein auf das Gebiet der Netzwerkkommunikationen und -protokolle. Insbesondere beziehen sich eine oder mehrere Ausführungsformen auf ein Verfahren und eine Einrichtung zum Konfigurieren des Datenebenenverhaltens auf Netzwerkweiterleitungselementen.
ALLGEMEINER STAND DER TECHNIK
Heutzutage erzeugen zahlreiche unabhängigen Hardware-Lieferanten (IHV = Independent Hardware Vendors) netzwerkanwendungsspezifische integrierte Schaltungen (ASIC = Applications Specific Integrated Circuits) zur Durchführung einer Unzähligkeit von Paketverarbeitungsaufgaben. Leider besteht die gegenwärtige Schnittstelle zu solchen ASICs im Allgemeinen aus Speicherabbildungsregistern, die entsprechendes Bit-Level-Verhalten und entsprechende Dokumentation aufweisen. Nicht alle IHVs beschränken jedoch ihre Produkte auf Register-Level-Beschreibungen, manche bieten C-Level- oder andere Software-Schnittstellen zur Hardware an. Diese Schnittstellen sind jedoch lediglich eine bequeme Widerspiegelung der zugrundeliegenden Register und unterscheiden sich daher von Lieferant zu Lieferant (IHV).
Des weiteren wird aufgrund der Register-Level-Beschreibungen oder ihrer Software-Schnittstellen zu den Hardware-ASICs die Benutzung dieser verschiedenen Produkte sehr erschwert. Tatsächlich bedeuten diese Register-Level-Modelle eine steil ansteigende Lernkurve und eine enge Bindung an einen OEM-Hersteller oder ISV-Lieferanten, der die integrierte Schaltung (ASIC) oder das Networking Silicon in einem Produkt verwenden möchte. Bei einer derartigen Mikro-Level-Beschreibung (d. h. Register-Bits) ist es schwierig Code zu schreiben, der auf alle diese verschiedenen ASICs wiederanwendbar ist. Ferner ist es schwierig, die Mikro-Level-Funktionalität des Networking Silicon der ASICs zu entziffern.
Seit kurzem gibt es einen Trend in der Netzwerkindustrie, ASICs, die relativ unflexibel sind, durch besser programmierbare, aber dennoch leistungsorientierte Netzwerkgeräte wie zum Beispiel Netzwerkprozessoren zu ersetzen. Leider befinden sich Netzwerkprozessoren allgemein noch in ihren Anfangsstadien und weisen kein abstraktes Programmiermodell oder keins auf, was hinreichend aussagekräftig und flexibel ist, um zusammen mit den Fortschritten im Prozessor wachsen zu können. Allgemein können Netzwerkelemente wie Schalter und Router in drei 1 logische Betriebskomponenten aufgegliedert werden: die Steuerebene, die Weiterleitungsebene und die Managementebene.
Im Allgemeinen führt die Steuerebene verschiedene Signalisierungs- und/oder Routingprotokolle aus und stellt der Weiterleitungsebene die gesamte Routing-Information bereit. Die Weiterleitungsebene trifft aufgrund dieser Information Entscheidungen und führt Arbeiten auf den Paketen aus, wie zum Beispiel Weiterleitung, Klassifizierung, Filterung usw. Eine orthogonale Managementebene managt die Steuer- und Weiterleitungsebenen. Die Einführung von standardisierten Anwendungsprogrammierschnittstellen (API) innerhalb der obengenannten Ebenen kann jedoch Systemlieferanten, OEM-Herstellern und Endbenutzern dieser Netzwerkelemente helfen, die von verschiedenen Lieferanten erhältlichen Bauteile aufeinander abzustimmen, um ein Gerät ihrer Wahl zu erhalten.
KURZBESCHREIBUNG DER ZEICHNUNGEN
Die verschiedenen Ausführungsformen der vorliegenden Erfindung sind anhand von Beispielen, die aber keine Einschränkungen bedeuten, in den Figuren der beigefügten Zeichnungen dargestellt, in denen
1 ein Blockdiagramm ist, das ein herkömmliches Computernetzwerk nach dem Stand der Technik zeigt.
2 ein Blockdiagramm ist, das ein herkömmliches Computernetzwerk, wie in 1 dargestellt, zeigt, das zudem verschiedene Netzwerkelemente enthält, die beim Routen von Paketen im Netzwerk, wie aus der Technik bekannt, zum Einsatz kommen.
3 ein Blockdiagramm ist, das ein herkömmliches Computernetzwerkelement zeigt, das innerhalb des in 2 dargestellten herkömmlichen Netzwerks zum Einsatz kommt.
4 ein Blockdiagramm ist, das ein Netzwerkelement gemäß einer erfindungsgemäßen Ausführungsform darstellt.
5 ein Blockdiagramm ist, das Netzwerkelemente, wie in 4 dargestellt, gemäß einer erfindungsgemäßen Ausführungsform verwendet.
6 ein Ablaufdiagramm ist, das ein Verfahren zum Konfigurieren des Datenebenenverhaltens auf Netzwerk-Weiterleitungselementen gemäß einer erfindungsgemäßen Ausführungsform darstellt.
7 ein Ablaufdiagramm ist, das ein Verfahren zur Verarbeitung der empfangenen Konfigurationsinformation gemäß einer erfindungsgemäßen Ausführungsform darstellt, wobei eine Steuerschnittstelle entsprechend einem Netzwerkprotokoll zum Einsatz kommt, das von der empfangenen Konfigurationsinformation implementiert wurde.
8 ein Ablaufdiagramm ist, das ein Verfahren zum Programmieren eines oder mehrerer Datenebenen-Weiterleitungselemente in Übereinstimmung mit einem Netzwerkprotokoll gemäß einer erfindungsgemäßen Ausführungsform darstellt.
9 ein Ablaufdiagramm ist, das ein Verfahren zum Programmieren eines oder mehrerer Datenebenen-Weiterleitungselemente in Übereinstimmung mit einem IPv4-Routingprotokoll (Internetprotokoll Version 4) gemäß einer erfindungsgemäßen Ausführungsform darstellt.
10 ein Ablaufdiagramm ist, das ein Verfahren zum Programmieren eines oder mehrerer Datenebenen-Weiterleitungselemente in Übereinstimmung mit einem IPv6-Routingprotokoll (Internetprotokoll Version 6) gemäß einer erfindungsgemäßen Ausführungsform darstellt.
11 ein Ablaufdiagramm ist, das ein Verfahren zum Programmieren eines oder mehrerer Datenebenen-Weiterleitungselemente in Übereinstimmung mit einem MPLS-Protokoll (Multi-Protocol Label Switching) gemäß einer erfindungsgemäßen Ausführungsform darstellt.
12 ein Ablaufdiagramm ist, das ein Verfahren zum Programmieren eines oder mehrerer Datenebenen-Weiterleitungselemente in Übereinstimmung mit einem DiffServ-Protokoll (Differential Services) gemäß einer erfindungsgemäßen Ausführungsform darstellt.
13 ein Ablaufdiagramm ist, das ein Verfahren zur Verarbeitung eines empfangenen Pakets innerhalb eines Weiterleitungselements darstellt, welches gemäß einer Steuerebenen-Steuerschnittstelle zur Implementierung eines Routingprotokolls gemäß einer erfindungsgemäßen Ausführungsform programmiert wurde.
AUSFÜHRLICHE BESCHREIBUNG
Es wird ein Verfahren und eine Einrichtung zum Konfigurieren des Datenebenenverhaltens auf Netzwerkweiterleitungselementen beschrieben. In einer Ausführungsform beinhaltet das Verfahren den Empfang von Protokollkonfigurationsinformation innerhalb einer Netzwerkelementsteuerebene, die einem Netzwerkprotokollstapel (Protokollanwendung) entnommen wird, wobei eine API-Schnittstelle (Netzwerkprotokollanwendungs-Programmierschnittstelle) zum Einsatz kommt. Nach Empfang der Protokollkonfigurationsinformation wird diese unter Einsatz einer entsprechenden Steuerschnittstelle der Steuerebene verarbeitet.
Nach Verarbeitung der Protokollkonfigurationsinformation programmiert die Steuerschnittstelle ein oder mehrere Datenebenen-Weiterleitungselemente des Netzwerkelements gemäß der empfangenen Protokollkonfigurationsinformation. Dementsprechend wird durch Bereitstellung ähnlicher Steuerschnittstellen für verschiedene Netzwerkprotokolle die Zusammenarbeit von Bauteilen verschiedener Lieferanten ermöglicht. Dies führt zu einer Lieferantenunabhängigkeit, woraus sich eine kürzere Zeitspanne bis zur Vermarktung, verbesserte Leistung, geringere Kosten und größere Innovationsmöglichkeiten für zukünftige Netzwerkelemente ergeben.
In der folgenden Beschreibung werden zum Zwecke der Erklärung zahlreiche spezifischen Beispiele angeführt, um ein gründliches Verständnis der Ausführungsformen der vorliegenden Erfindung zu vermitteln. Für den Fachmann ist jedoch offensichtlich, daß die verschiedenen erfindungsgemäßen Ausführungsformen ohne einige dieser spezifischen Details praktiziert werden können. Ferner beschränkt sich die nachfolgende Beschreibung auf einen Untersatz möglicher Ausführungsformen und ihrer zugehörigen Zeichnungen, ohne eine erschöpfende Liste aller möglichen Implementierungen der erfindungsgemäßen Ausführungsformen vorzusehen. In manchen Fällen werden gut bekannte Strukturen und Geräte in Blockdiagrammform dargestellt, um eine Verwischung der Details der verschiedenen erfindungsgemäßen Ausführungsformen zu vermeiden.
Systemarchitektur
Im Blockdiagramm von 1 ist ein herkömmliches Netzwerk 100 mit einem Internet Host 102, der über das Internet mit Hostcomputern 140 (140-1, ..., 140N) verbunden ist, dargestellt. Im Allgemeinen erfolgt das Weiterleiten von Information zwischen dem Internet Host 102 und den Hostcomputern 140 mit herkömmlichen Mitteln zum Übertragen von Datenpaketen. Die verschiedenen Pakete werden innerhalb des Internets vom Internet Host 102 an die verschiedenen Hostcomputer 140 weitergeleitet. Obwohl dieses Modell erfolgreich für die Übertragung von herkömmlicher verpackter Information ist, gibt es neuerdings eine Reihe von Anwendungen, wie Telekonferenz- und Multimedienanwendungen, die empfindlich gegenüber Verzögerungen innerhalb herkömmlicher Netzwerke sind.
Dies hatte zur Folge, daß die Anforderung der verfügbaren Netzwerke zur Verbesserung sowie Variierung der Dienstgüte (QoS), Switching (Vermittlung), Forwarding (Weiterleitung) und dergleichen durch das Auftauchen von Multimedien- und Echtzeitanwendungen, die Netzwerke gemäß der Darstellung in 1 verwenden, getrieben wurde. Desgleichen benötigen verschiedene Informations(-Pakete), die durch Netzwerk 100 weitergeleitet werden können, möglicherweise verschiedene spezialisierte Protokollaktivitäten. Leider verwenden Netzwerke gemäß der Darstellung in 1 ein traditionelles „Best-Effort” Servicemodell, das nicht im Voraus eine Bandbreite zum Handhaben des Netzwerkverkehrs bereitstellt, sondern einfach Pakete unter Einsatz der aktuell verfügbaren Bandbreite auf „Best Effort-Basis” routet. Demzufolge sind im ganzen Internet unterschiedliche Warteschlangenverzögerungen und Verstopfungen durchaus üblich.
Das durch Netzwerk 100 implementierte „Best-Effort” Servicemodell basiert auf dem TCP/IP Protokoll (Transmission Control Protocol/Internet Protocol). Genau genommen bezieht sich die Protokollimplementierung auf die IP-Version 4 (IPv4). Im Allgemeinen ist IPv4 die meist installierte Version des Internet-Protokolls, das heutzutage im Einsatz steht. Wie dem Fachmann bekannt sein wird, ist eine IP-Adresse eine 32-Bit-Zahl, die jeden Sender oder Empfänger von Information identifiziert, die paketweise über das Internet geschickt wird. Eine IP-Adresse besteht normalerweise aus zwei Teilen – einer Kennung eines bestimmten Netzwerks im Internet, und einer Kennung des jeweiligen Geräts innerhalb des Netzwerks.
Als solches ist das Internet eine Zwischenverbindung zwischen vielen individuellen Netzwerken, und IPv4 ist ein Satz von Regeln für ein Netzwerk, das mit einem anderen Netzwerk kommuniziert, vorausgesetzt, daß das Netzwerk seine eigene Internetadresse und die der anderen Netzwerke, mit denen es kommuniziert, kennt. Leider steht die von IPv4 vorgegebene 32-Bit-IP-Adresse kurz davor, überholt zu werden. In anderen Worten, es ist wahrscheinlich, daß aufgrund des Internet-Wachstums in Abwesenheit einer neuen Architektur die Anzahl der möglichen Netzwerkadressen, die das von IPv4 bereitgestellte Adressiersystem benutzen, bald überschritten sein wird. Desgleichen ist das vom aktuellen TCP/IP-Protokoll bereitgestellte „Best-Effort” Servicemodell für verschiedene aktuelle als auch zukünftige Netzwerkanwendungen unzureichend.
Daher wurde eine neue Version (die nächste Generation) des Internet-Protokolls implementiert. Wie dem Fachmann bekannt sein wird, ist dieses Internet-Protokoll der nächsten Generation die Version IPv6. Die offensichtliche Verbesserung in IPv6 gegenüber IPv4 besteht darin, daß die IP-Adressen von 32-Bits auf 128-Bits erweitert wurden. Diese Erweiterung bedeutet, daß mit einem beträchtlichen Wachstum des Internets gerechnet wird, und deshalb Vorsorge zu treffen war, dem bevorstehenden Mangel an Netzadressen entgegenzuwirken. IPv6 stellt ferner Regeln für drei Arten von Adressierung auf: Unicast (ein Host zu einem anderen Host); Anycast (ein Host zum Nächsten von mehreren Hosts) und Multicast (ein Host zu vielen Hosts).
Ferner stellt IPv6 verschiedene Verbesserungen bereit. Zum Beispiel können Pakete, die einem Ende-Ende-Pfad (oder „Fluß”) angehören, beispielsweise als Teil einer Multimedienpräsentation identifiziert werden, die eine Echtzeit-Ankunft erfordert. Demzufolge kann Paketen, die eine Echtzeit-Auslieferung erfordern oder empfindlich gegenüber Verzögerungen sind, durch Bereitstellung dieser Identifikation eine gegenüber dem normalen Netzwerkverkehr höhere Dienstgüte (QoS) gegeben werden.
Zum Beispiel zeigt 2 ein Blockdiagramm des in 1 dargestellten Netzwerks, um die verschiedenen Netzwerkelemente zwischen beispielsweise einem Echtzeit-Anwendungsserver (Quellencomputer) 200 und einem Zielcomputer 220 zu verdeutlichen. Aufgrund der Tatsache, daß das Netzwerk gemäß des IPv4-Routingprotokolls konfiguriert ist, wird der empfangene Netzwerkverkehr auf der Basis des „Best-Effort” Servicemodells weitergeleitet. Dies führt dazu, daß bei der Übertragung von verpackten Daten zwischen dem Echtzeit-Anwendungsserver 200 und einem Zielcomputer 220 verschiedene Routing-Verzögerungen eintreten aufgrund der Tatsache, daß im ganzen Internet aufgrund des weitverbreiteten Einsatzes des Internets Verstopfungen durchaus üblich sind. Zum Beispiel würde während der Spitzenverkehrszeiten die Übertragung von in Echtzeit verpackten Daten unter derart großen Verzögerungen leiden, daß die Anwendung auf dem Zielcomputer unbrauchbar würde.
Ein aktuelles Netzwerkprotokoll (Modell) zur Bereitstellung von Service-Differenzierung (variierende QoS (Dienstgüte)) für Verkehrsflüsse ist das Modell für differenzierte Dienste (DiffServ). Das DiffServ-Modell stellt qualitative Differenzierung für „Flow Aggregates” (Ansammlung von Flüssen) bereit, im Gegensatz zu harten Garantien wie „Delay Bounds” (Verzögerungsgrenzen) und „Assured Bandwidth” (zugesicherte Bandbreite), die von dem Modell für integrierte Dienste (IntServ) bereitgestellt werden. Zum Beispiel kann die qualitative Differenzierung, die vom DiffServ-Modell bereitgestellt wird, auf eine höhere Priorität für Klasse A gegenüber Klasse B eingerichtet werden. Ferner stellt das DiffServ-Modell Datenpfadelemente (DPE) wie „Classifiers” (Klassifizierer), „Meters” (Meßgeräte), „Droppers” (Ableger), „Queues” (Warteschlangen) und „Schedulers” (Planer) bereit.
Ein weiteres Netzwerkprotokoll, welches beispielsweise zur Beschleunigung des Netzwerkverkehrs verwendet werden könnte, um Anwendungen wie Audio- und Sprachanwendungen zu implementieren, die sehr empfindlich auf Warteschlangenverzögerungen und Verstopfungen im Netzwerk reagieren, ist das MPLS-Protokoll (Multi-Protokol Label Switching). Das MPLS-Protokoll ist eine normale genehmigte Technologie zur Beschleunigung des Netzwerkverkehrsflusses sowie eines vereinfachten Managements desselben. MPLS beinhaltet des Einrichten eines bestimmten Pfads für eine gegebene Folge von Paketen, die durch ein Label (Etikett) in jedem Paket identifiziert werden. Dies führt zu Einsparungen von Zeit, die allgemein der Router benötigt, um Adressen zum nächsten Knoten nachzuschlagen, an den das Paket weitergeleitet werden soll.
Außerdem wird MPLS auch als Multi-Protokoll bezeichnet, weil es, wie in der Technik bekannt, mit dem Internet-Protokoll, dem ATM-Protokoll (Asynchronous Transfer Mode) und dem Frame-Delay-Netzwerkprotokoll zusammenarbeitet. Ferner erlaubt MPLS das Weiterleiten der meisten Pakete auf Layer-2 Level (Switching) gegenüber Layer-3 Level (Routing). Darüber hinaus stellt MPLS, neben der Beschleunigung des Verkehrs, auch ein vereinfachtes Management eines Netzwerks hinsichtlich Dienstgüte (QoS) und Verkehrstechnik (Traffic Engineering) bereit. Demgemäß sind Netzwerke, die das MPLS-Protokoll implementieren, fähig, eine hinreichende Dienstgüte (QoS) für verschiedene Netzwerkverkehrsmischungen bereitzustellen. Wie hier beschrieben, werden die oben beschriebenen Switching- und QoS-Protokolle kollektiv als „Netzwerkprotokolle” bezeichnet.
Unter Bezugnahme auf 3 ist zu sagen, daß in 3 ein herkömmliches Netzwerkelement 302, wie in Netzwerk 300 von 2 verwendet, dargestellt ist. Wie dargestellt, beinhaltet das Netzwerkelement eine Weiterleitungsebene 380 mit einem Eintrittsfilterblock 304, einem Weiterleitungsentscheidungsblock 390 und einem Austrittsfilterblock 306, um eingehende Pakete, wie durch die Steuerebene 310 diktiert, zu einem Zielort zu routen. Leider stellt das Netzwerkelement 302 eng gekoppelte Weiterleitungs- und Steuerebenen innerhalb eines einzigen Geräts zur Verfügung. Deshalb erfordert die Implementierung variierender QoS wie von verzögerungsempfindlichen Anwendungen gefordert, innerhalb des Netzwerkelements (302) eine intime Kenntnis einer innerhalb des Geräts benutzten firmenspezifischen Schnittstelle.
Ein kürzlicher Trend in der Netzwerkindustrie besteht jedoch darin, herkömmliche Netzelemente, die relativ unflexibel sind, durch besser programmierbare, aber trotzdem leistungsorientierte Netzwerkgeräte, wie zum Beispiel durch Netzwerkprozessoren zu ersetzen. Leider befinden sich Netzwerkprozessoren noch in ihren Anfangsstadien und besitzen kein abstraktes Programmiermodell oder keins, was genügend aussagekräftig und flexibel wäre, um zusammen mit den Fortschritten im Prozessor selbst wachsen zu können.
Allgemein gesagt können Netzwerkelemente wie Schalter und Router in drei logische Betriebskomponenten aufgegliedert werden: die Steuerebene, die Weiterleitungsebene und die Managementebene. Zum Beispiel führt die Steuerebene verschiedene Signalisier- oder Routingprotokolle aus und stellt der Weiterleitungsebene alle Routinginformationen bereit. Die Weiterleitungsebene trifft Entscheidungen aufgrund dieser Information und nimmt Arbeiten auf den Paketen vor, wie zum Beispiel Weiterleitung, Klassifizierung, Filterung usw. Eine orthogonale Ebene managt die Steuer- und Weiterleitungsebenen.
Die Einführung von standardisierten Anwendungsprogrammier-schnittstellen (API) innerhalb der obengenannten Ebenen kann jedoch Systemlieferanten, OEM-Herstellern und Endbenutzern dieser Netzwerkelemente helfen, die von verschiedenen Lieferanten verfügbaren Bauteile aufeinander abzustimmen, um ein Gerät ihrer Wahl zu erhalten. Demgemäß ist in 4 ein Blockdiagramm eines Netzwerkelements 400 dargestellt, bei dem gemäß einer erfindungsgemäßen Ausführungsform die Steuerebene 410 und die Datenebene 430 getrennt und über die Zusammenschaltung 402 miteinander verbunden sind.
In einer Ausführungsform ermöglicht die Steuerebene 410 die Abfrage der Datenebene zur Bestimmung von Information, die zur Programmierung des Weiterleitungselements der Datenebene 430 benötigt wird. Dies erlaubt einen größeren Grad an Allgemeingültigkeit bei der Steuerung des spezifischen Verhaltens in Netwerkweiterleitungselementen. Wie hier beschrieben, werden die verschiedenen Parameter und die Information zur Erstellung einer Tabelle und deren Ausfüllung mit Werten zur Implementierung des entsprechenden Protokolls kollektiv unter dem Ausdruck „Protokollkonfigurationsinformation” zusammengefaßt.
Folglich ist die Steuerschnittstelle 420 fähig, ein ausgewähltes Datenebenen-Weiterleitungselement zu programmieren, um innerhalb der Datenebene 430 Drittpartei-Netzwerkprotokollstapel (Protokollanwendungen) ungeachtet der Lieferantenquelle der Datenebene zu programmieren. In einer Ausführungsform programmiert die Steuerschnittstelle 420 die Datenebene 430 gemäß der Protokollkonfigurationsinformation, die der Protokollanwendung durch eine mit dem Protokoll korrespondierende API entnommen wurde. Zum Beispiel implementiert das Netzwerkelement 400, wie dargestellt, die IPv4-, IPv6-Routingprotokolle und auch die MPLS- und DiffServ-Netzwerkprotokolle („Netzwerkprotokolle”) über die Anwendungen 424 und 426. Desgleichen ist auch eine Management/Konfigurationsanwendung 422 vorgesehen.
Um die verschiedenen Protokollanwendungen von verschiedenen Drittpartei-Entwicklern zu ermöglichen, stellt eine erfindungsgemäße Ausführungsform APIs für beispielsweise das IPv4-Routingprotokoll, das IPv6-Routingprotokoll, das MPLS-Netzwerkprotokoll und das DiffServ-Netzwerkprotokoll bereit. Verschiedene APIs für gewünschte zusätzliche Protokolle können jedoch gemäß Ausführungsformen der vorliegenden Erfindung implementiert werden. Demgemäß kann durch Einsatz einer API in Übereinstimmung mit Ausführungsformen der vorliegenden Erfindung eine Drittpartei-Protokollanwendung mit einer Steuerebene von Lieferant A versehen werden, um ein bestimmtes Protokoll zu implementieren, wie es vom Drittpartei-Softwareentwickler innerhalb einer Datenebene von Lieferant B gewünscht wird.
In einer Ausführungsform werden die Kommunikationsschnittstellen sowie auch die Implementierung des Protokolls innerhalb der Datenebene 430 von der betreffenden Protokoll-API gehandhabt. In anderen Worten, die Steuerschnittstelle 420 engagiert die APIs für die oben beschriebenen Protokolle. So kommt es, das durch Einfügung einer entsprechenden API in eine herkömmliche Protokollanwendung plattform-unabhängige Protokollanwendungen bereitgestellt werden. Als solches stellt in einer Ausführungsform die entsprechende API Protokollkonfigurationsinformation bereit, die der Protokollanwendung für Steuerebene 420 entnommen wurde.
In einer Ausführungsform benutzt die Steuerebene 420 diese Protokollkonfigurationsinformation zur Programmierung von Weiterleitungselementen der Datenebene 430, um das Protokoll zu implementieren. Außerdem wird die Kommunikation zwischen der Steuerschnittstelle 420 und der Datenebene 430 dadurch erzielt, daß zum Beispiel ein Zusammenschaltungs-Meldungsprotokoll oder dergleichen verwendet wird. Zum Beispiel kann das IPv6-Routingprotokoll innerhalb von Weiterleitungselement 440 implementiert werden. Wie dargestellt, werden die IPv6-Weiterleitungstabellen sowie die Nachbartabelle 460 beim Hochfahren des Geräts innerhalb von Weiterleitungselement 440 gebildet. Außerdem werden, wie von der Protokollkonfigurationsinformation vorgegeben, die schnittstellenspezifischen Tabelleneinträge (462 und 464) erzeugt und in die entsprechende Tabelle (460) eingetragen, um das Routen von empfangenen Paketen über die Schnittstellen 442 vorzugeben.
Desgleichen können auch MPLS-, FTN-(Forward Equivalent Class (FEC) to Nexthop Label-Forwarding Entry (NHLFE)) und ILM-Tabellen (Incoming Label Map) mit spezifischen Einträgen (452, 454 und 456) innerhalb von Weiterleitungselement 440 implementiert werden. Die spezifischen Einträge werden von der entsprechenden LDP-Anwendung (LDP = Label Distribution Protocol) vorgegeben, um das Verhalten von Weiterleitungselementen beim Empfang von entsprechenden Pakete über die Schnittstellen 442 zu steuern. Desgleichen kann das IPv4-Routingprotokoll wie auch das DiffServ-Routingprotokoll innerhalb von Weiterleitungselement 470 implementiert werden.
Diese Möglichkeit wird aufgrund der Tatsache bereitgestellt, daß in einer Ausführungsform die Steuerschnittstelle 420 den Mechanismus bereitstellt, eins von vielen spezifischen Elementen innerhalb der Datenebene 430 anzupeilen. Das heißt, ein einziger spezifischer Tabelleneintrag innerhalb einer oder mehrerer Tabellen innerhalb eines von vielen Weiterleitungselementen kann angesprochen werden. Desgleichen stellt in einer Ausführungsform die Steuerschnittstelle einen Mechanismus für Steuerebenen-Bauteile (Protokollanwendungen) bereit, die Weiterleitungselemente abzufragen, um Parameter und Ressourcen der Datenebene zu bestimmen.
In 5 ist ein Blockdiagramm eines Netzwerks 500 dargestellt, bei dem Netzwerkelemente 400, wie in 4 dargestellt gemäß einer Ausführungsform der vorliegenden Erfindung zum Einsatz kommen. Wie dargestellt, ist ein Echtzeit-Anwendungsserver 200 fähig, eine verbesserte/variierende QoS zu empfangen, die zum Beispiel vom DiffServ-Netzwerkprotokoll innerhalb von Netzwerkelement 400 bereitgestellt wird. Auch andere verschiedene Quellencomputer benötigen vielleicht ein separates Routing-/Netzwerkprotokoll wie zum Beispiel IPv4- (für alte Anwendungen) und IPv6-Routingprotokolle, MPLS-Netzwerke oder dergleichen. Diese Protokolle können innerhalb des Netzwerkelements unter Einsatz von zum Beispiel Drittpartei-Protokollanwendungen einschließlich einer entsprechenden Protokoll-API gemäß einer erfindungsgemäßen Ausführungsform implementiert werden.
Ferner ist die Steuerschnittstelle 420 innerhalb der Netzwerkelemente 400 vollkommen asynchron gestaltet, um jede Art von Zusammenschaltungstechnologie zur Zusammenschaltung der Steuer- und Datenebenen zu unterstützen. Steuerebenen und Datenebenen können unter Einsatz von Netzwerktechnologien wie dem Ethernet, Kabelleitungen, einem Bus oder Lichtfasern miteinander verbunden werden. Desgleichen könnte die Verbindung zwischen Steuerebene und Datenebene durch Bustechnologie wie kompakte PCI (Peripheral Component Interconnect – Periphere Komponentenzusammenschaltung) verwirklicht werden, oder die Steuer- und Datenebenen könnten zusammengelegt und über Interprozeßkommunikationen miteinander verbunden werden. Im Folgenden sollen prozeßtechnische Verfahren zur Implementierung von Ausführungsformen der vorliegenden Erfindung beschrieben werden.
Arbeitsweise
In 6 ist ein Ablaufdiagramm für ein Verfahren 600 zum Konfigurieren des Datenebenenverhaltens auf den Netzwerkweiterleitungselementen von, zum Beispiel, Netzwerkelement 400 in 4 gemäß einer erfindungsgemäßen Ausführungsform dargestellt. Bei Verfahrensblock 602 wird die Protokoll-konfigurationsinformation, die einer Protokollanwendung entnommen wurde, innerhalb einer Netzwerkelement-Steuerebene empfangen. In einer Ausführungsform implementiert die Protokollanwendung ein Netzwerk-/Routingprotokoll unter Einsatz einer Protokollanwendungs-Programmierschnittstelle (API), die für die Entnahme der Protokollkonfigurationsinformation verantwortlich ist.
In einer Ausführungsform unterstützt die Protokoll-API Netzwerkprotokolle wie zum Beispiel das DiffServ-Netzwerkprotokoll, das MPLS-Netzwerkprotokoll sowie die IPv4- und IPv6-Routingprotokolle. Demgemäß ist die Implementierung des entsprechenden Protokolls, das von der Protokollkonfigurationsinformation empfangen wurde, für den Anwendungsprogrammierer nicht sichtbar. Nach Empfang der Protokollkonfigurationsinformations-Anwendung wird bei Verfahrensblock 604 die empfangene Protokollkonfigurationsinformation verarbeitet, wobei eine Steuerschnittstelle zum Einsatz kommt, die dem Protokoll entspricht, das von der empfangenen Protokollanwendung implementiert wurde.
Zum Beispiel besteht, wie in 4 dargestellt, die Steuerschnittstelle 420 aus den Steuerschnittstellen IPv4, IPv6, MPLS und DiffServ. Daraus folgt, daß die Steuerschnittstelle 420 eine entsprechende Protokollschnittstelle zur Verarbeitung der Anwendung bestimmt, die zum Beispiel von einem Drittpartei-Entwickler empfangen wurde. Es werden also nach der Auswahl bei Verfahrensblock 620 ein oder mehrere Datenebenen-Weiterleitungselemente des Netzwerkelements gemäß der Protokollkonfigurationsinformation programmiert, die der Protokollanwendung nach beispielsweise 4 entnommen wurde.
In 7 ist ein Ablaufdiagramm eines Verfahrens 606 zur Verarbeitung von empfangener Protokollkonfigurationsinformation bei Verfahrensblock 604 nach 6 dargestellt, das einer erfindungsgemäßen Ausführungsform entspricht. Bei Verfahrensblock 608 wählt die Steuerschnittstelle ein Weiterleitungselement innerhalb der Datenebene aus, um das Netzwerk-Routing- oder Nichtrouting-Protokoll zu implementieren, das mit der empfangenen Protokollkonfiguration-information verknüpft ist. Zum Beispiel könnte die Steuerschnittstelle 420 das Weiterleitungselement 440 auswählen, um das IPv6-Routings-Protokoll zu implementieren.
Als nächstes werden bei Verfahrensblock 610 eine oder mehrere schnittstellenspezifischen Tabellen bestimmt, die innerhalb des ausgewählten Weiterleitungselements gebildet werden müssen. Nach Bestimmung bei Verfahrensblock 612 werden ein oder mehrere Einträge innerhalb der schnittstellenspezifischen (oder protokollspezifischen) Tabellen von der Steuerschnittstelle gemäß der Protokollkonfigurationsinformation bestimmt. Demnach trifft ein Weiterleitungselement, das die schnittstellenspezifischen Tabellen enthält, Routing-Entscheidungen aufgrund der Einträge in den schnittstellenspezifischen Tabellen. Zum Beispiel werden Einträge 1–3 der MPLS-Tabelle 450 zusätzlich zu den Einträgen 1 und 2 der IPv6-Tabelle 460 bestimmt.
In 8 ist ein Ablaufdiagramm des Verfahrens 622 zur Programmierung der Datenebenen-Weiterleitungselemente von Verfahrensblock 620 nach 6 dargestellt, das einer erfindungsgemäßen Ausführungsform entspricht. Bei Verfahrensblock 624 wird nach Abfrage der von der Datenebene bereitgestellten Protokoll-Ressource das von der Protokollkonfigurationsinformation angegebene Netzwerkprotokoll bei der Datenebene beim Hochfahren des Geräts angemeldet, um den Empfang von Ereignissen von der Datenebene zu ermöglichen. In anderen Worten, während der verschiedenen Verarbeitungsabläufe innerhalb des Weiterleitungselements kann das implementierte Protokoll ein Ereignis auslösen, das die Kommunikation mit der Steuerebene erfordert, um das nachfolgende Verarbeitungsverhalten innerhalb der Datenebene zu bestimmen.
Bei Verfahrensblock 626 wählt die Steuerschnittstelle das Weiterleitungselement aus einem oder mehreren Weiterleitungselementen der Netzwerkdatenebene, wie zum Beispiel das Weiterleitungselement 440 (4), aus. Als nächstes werden bei Verfahrensblock 628 eine oder mehrere schnittstellenspezifischen Tabellen, die innerhalb des ausgewählten Weiterleitungselements beim Hochfahren des Geräts erzeugt wurden, ausgewählt. Nach Auswahl bei Verfahrensblock 630 erzeugt die Steuerschnittstelle einen oder mehrere Einträge in den schnittstellenspezifischen Tabellen des ausgewählten Weiterleitungselements, wie von der Protokollkonfiguration-information bestimmt, die einer empfangenen Protokollanwendung durch eine entsprechende Protokoll-API entnommen wurde.
In 9 ist ein Ablaufdiagramm des Verfahrens 632 zur Programmierung des Datenebenenverhaltens von Verfahrensblock 620 nach 6 dargestellt, um ein IPv4-Routingprotokoll in Übereinstimmung mit einer erfindungsgemäßen Ausführungsform zu implementieren. Bei Verfahrensblock 634 wird das IPv4-Routingprotokoll bei der Netzwerkelement-Datenebene beim Hochfahren des Geräts angemeldet, um den Empfang von Ereignissen von der Datenebene zu ermöglichen. Bei Verfahrensblock 636 wird eine IPv4 Weiterleitungstabelle innerhalb des ausgewählten Weiterleitungselements beim Hochfahren des Geräts erzeugt. Bei Verfahrensblock 638 wird eine ARP-Tabelle (Address Resolution – Adressenermittlung) innerhalb des ausgewählten Weiterleitungselements beim Hochfahren des Geräts erzeugt.
Als nächstes wird bei Verfahrensblock 640 ein Weiterleitungselement innerhalb der Datenebene ausgewählt, um ein IPv4-Routingprotokoll zu implementieren. Bei Verfahrensblock 642 wird bestimmt, ob eine Anforderung von der Protokollanwendung empfangen wurde, die Routen- und ARP-Aktualisierungsanforderungen enthalten kann. Bei Empfang einer Routen-Anforderung werden bei Verfahrensblock 644, je nach empfangener Aktualisierungsanforderung, IPv4-Routing-Einträge entweder zur Weiterleitungstabelle hinzugefügt oder aus ihr gelöscht. Bei Empfang einer ARP-Anforderung werden bei Verfahrensblock 646, je nach empfangener Anforderung, IPv4-Einträge entweder zur Adressenermittlungstabelle (Address Resolution) hinzugefügt oder aus ihr gelöscht. Dementsprechend werden Verfahrensblöcke 642–646 so lange wiederholt, bis die Programmierung der Weiterleitungselemente abgeschlossen ist.
In 10 ist ein Ablaufdiagramm eines Verfahren 650 zur Programmierung der Datenebene von Verfahrensblock 620 nach 6 dargestellt, um ein IPv6-Routingprotokoll in Übereinstimmung mit einer erfindungsgemäßen Ausführungsform zu implementieren. Bei Verfahrensblock 652 wird das IPv6-Routingprotokoll bei der Datenebene während des Hochfahrens des Geräts angemeldet, um den Empfang von Ereignissen von der Datenebene, wie oben angegeben, zu ermöglichen. Bei Verfahrensblock 654 wird eine IPv6-Weiterleitungstabelle innerhalb des ausgewählten Weiterleitungselements während des Hochfahrens des Geräts erzeugt. Nach Auswahl bei Verfahrensblock 656 wird innerhalb des ausgewählten Weiterleitungselements während des Hochfahrens des Geräts eine IPv6-Nachbartabelle erzeugt.
Als nächstes wird bei Verfahrensblock 658 ein Weiterleitungselement aus der Netzwerkelement-Datenebene ausgewählt. Bei Verfahrensblock 660 wird bestimmt, ob eine Anforderung von der Protokollanwendung empfangen wurde, die Routen- und Nachbartabellen-Aktualisierungsanforderungen enthalten kann. Bei Empfang einer Routen-Anforderung werden bei Verfahrensblock 662, je nach empfangener Anforderung, IPv6-Routing-Einträge entweder zur Weiterleitungstabelle hinzugefügt oder aus ihr gelöscht. Bei Empfang einer Nachbartabellen-Aktualisierungsanforderung werden bei Verfahrensblock 664, je nach empfangener Anforderung, IPv6-Einträge entweder zur Nachbartabelle hinzugefügt oder aus ihr gelöscht. Dementsprechend werden Verfahrensblöcke 660–664 so lange wiederholt, bis die Programmierung der Weiterleitungselemente abgeschlossen ist.
In 11 ist ein Ablaufdiagramm eines Verfahrens 670 zur Programmierung von Weiterleitungselementen der Datenebene bei Verfahrensblock 620 nach 6 dargestellt, um ein MPLS-Netzwerkprotokoll in Übereinstimmung mit einer erfindungsgemäßen Ausführungsform zu implementieren. Bei Verfahrensblock 672 wird eine FTN-Tabelle innerhalb eines ausgewählten Weiterleitungselements während des Hochfahrens des Geräts erzeugt, um das MPLS-Vermittlungsprotokoll zu implementieren. Bei Verfahrensblock 674 wird eine ILM-Tabelle innerhalb des ausgewählten Weiterleitungselements während des Hochfahrens des Geräts erzeugt. Als nächstes wird bei Verfahrensblock 676 eine FTN-DiffServ-Kontexttabelle innerhalb des ausgewählten Weiterleitungselements während des Hochfahrens des Geräts erzeugt.
Nach ihrer Erstellung wird bei Verfahrensblock 678 eine ILM-DiffServ-Kontexttabelle innerhalb des ausgewählten Weiterleitungselements während des Hochfahrens des Geräts erzeugt. Nach ihrer Erstellung wird bei Verfahrensblock 680 bestimmt, ob eine Protokoll-Anwendungsanforderung erhalten wurde. Wenn eine FTN-Anforderung empfangen wurde, werden Verfahrensblöcke 682 und 684 ausgeführt. Wenn jedoch eine ILM-Anforderung empfangen wurde, werden Verfahrensblöcke 686 und 688 ausgeführt. Andernfalls kehrt der Steuerfluß zu Verfahrensblock 620 (6) zurück, was allgemein dann erfolgt, wenn die Programmierung der Datenebenen-Weiterleitungselemente abgeschlossen ist, nachdem Verfahrensblöcke 680–688 für jede Protokoll-Anwendungsanforderung wiederholt werden.
Dementsprechend werden bei Verfahrensblock 682 MPLS FTN Einträge nach Erhalt einer MPLS FTN Eintragsanforderung entweder zur FTN-Tabelle hinzugefügt oder aus ihr gelöscht. Desgleichen werden bei Verfahrensblock 684 bei Erhalt einer MPLS-E-LSP Konfigurationseintragsanforderung MPLS E-LSP (Explicit Route Label Switch Path) Konfigurationseinträge entweder zu den FTN DiffServ-Kontextabellen hinzugefügt oder aus diesen gelöscht. Andernfalls werden bei Verfahrensblock 686 bei Empfang einer MPLS ILM Eintragsanforderung MPLS ILM Einträge entweder zur ILM-Tabelle hinzugefügt oder aus ihr gelöscht. Desgleichen werden bei Verfahrensblock 686 bei Erhalt einer MPLS E-LSP Vorkonfigurations-Eintragsanforderung MPLS E-LSP-Vorkonfigurationseinträge zur ILM DiffServ Kontexttabelle hinzugefügt oder aus dieser gelöscht.
In 12 ist ein Ablaufdiagramm eines Verfahrens 690 zur Programmierung von Datenebenen-Weiterleitungselementen von Verfahrensblock 620 nach 6 dargestellt, um ein DiffServ-Netzwerkprotokoll in Übereinstimmung mit einer erfindungsgemäßen Ausführungsform zu implementieren. Bei Verfahrensblock 692 wird eine Mehrzahl von DiffServ-Tabellen innerhalb des ausgewählten Weiterleitungselements erzeugt, um während des Hochfahrens des Geräts das DiffServ-Routingprotokoll, zum Beispiel DiffServ DPE, zu implementieren. In einer Ausführungsform kann jeder Aufruf (Protokollanwendungsanforderung) Einträge eines der folgenden Typen beinhalten: Filter, Meter (Meßgerät), Marker (Markierung), Warteschlange oder Scheduler. Bei Verfahrensblock 694 werden Filtereinträge in einer DiffServ Klassifizierungstabelle entweder hinzugefügt oder gelöscht, wenn eine Klassifizierungstabellen-Eintragsanforderung wird. Bei Verfahrensblock 696 werden Meter-Einträge entweder zu einer DiffServ Meter Tabelle hinzugefügt, oder in dieser geändert oder gelöscht, wenn eine Meter-Eintragsanforderung empfangen wird.
Ferner werden bei Verfahrensblock 698 Markierungseinträge zu einer DiffServ-Markierungstabelle hinzugefügt, geändert oder aus dieser gelöscht, wenn eine Markierungstabellen-Eintragsanforderung empfangen wird. Bei Verfahrensblock 700 werden Dropper-Einträge (Ablegereinträge) zu einer innerhalb des ausgewählten Weiterleitungselements erzeugten algorythmischen DiffServ-Dropper-Tabelle hinzugefügt, in dieser geändert oder gelöscht, wenn eine Dropper-Eintragsanforderung erhalten wird. Bei Verfahrensblock 702 werden Abfrageeinträge zu einer DiffServ-Warteschlange hinzugefügt, in dieser geändert oder gelöscht, wenn eine Warteschlangen-Eintragsanforderung erhalten wird. Schließlich werden bei Verfahrensblock 704 Scheduler-Einträge zu einer DiffServ-Scheduler-Tabelle entweder hinzugefügt, in dieser geändert oder gelöscht, wenn eine Schedulerrabellen-Eintragsanforderung erhalten wird.
Schließlich ist in 13 ein Ablaufdiagramm eines Verfahrens 710 für das Verhalten, beispielsweise eines Netzwerkelements, dargestellt, welches eine Steuerschnittstelle in Übereinstimmung mit einer erfindungsgemäßen Ausführungsform implementiert. Bei Verfahrensblock 712 wird bestimmt, ob ein Paket empfangen wurde. Nach Empfang bei Verfahrensblock 714 wird bestimmt, ob ein Ereignis, wie zum Beispiel ein „Protokoll-nichtunterstützt” Ereignis von dem empfangenen Paket ausgelöst wurde. Wenn ein Ereignis ausgelöst wurde, wird Verfahrensblock 716 ausgeführt. Bei Verfahrensblock 716 wird eine Weiterleitungselement-Anwendung, die das Netzwerkprotokoll entsprechend des empfangenen Pakets implementiert, von dem Ereignis benachrichtigt. In einer Ausführungsform kann die Benachrichtigung das Weiterleiten des empfangenen Pakets an ein verantwortliches Weiterleitungselement beinhalten.
Andernfalls wird bei Verfahrensblock 718 ein Weiterleitungselement bestimmt, das mit einer oder mehreren schnittstellenspezifischen Tabellen entsprechend dem mit dem Paket verknüpften Netzwerkprotokoll programmiert wurde. Nach der Bestimmung wird bei Verfahrensblock 720 bestimmt, ob das Nachschlagen in einer Nachschlagetabelle ein Ereignis, wie zum Beispiel „fehlender Eintrag/kein Eintrag gefunden” ausgelöst hat. Wenn ein Ereignis ausgelöst wurde, wird Verfahrensblock 722 ausgeführt. Bei Verfahrensblock 722 wird eine Weiterleitungselement-Anwendung, die das Netzwerkprotokoll entsprechend dem empfangenen Paket implementiert, von dem Ereignis benachrichtigt. In einer Ausführungsform könnte ein „kein-Eintrag-gefunden” Ereignis eine DROP-Aktion des empfangenen Pakets durch das Weiterleitungselement auslösen.
Andernfalls wird bei Verfahrensblock 724 das Paket durch das Weiterleitungselement gemäß des schnittstellenspezifischen Tabelleneintrags verarbeitet, der dem mit dem Paket verknüpften Netzwerkprotokoll entspricht und aufgrund der Protokollkonfigurationsinformation erstellt wurde. In einer Ausführungsform kann die Kommunikation zwischen der Steuerebene und der Datenebene zum Beispiel durch ein Zusammenschaltungs-Meldungsprotokoll bereitgestellt werden, wie aus der Technik bekannt. In anderen Ausführungsformen können Meldungs- oder Kommunikationsprotokolle zwischen der Steuerebene und der Datenebene genutzt werden.
Demgemäß kann bei Einsatz von Ausführungsformen der vorliegenden Erfindung die Entwicklung von Drittpartei-Protokollanwendungen für zum Beispiel Netzwerkprozessoren implementiert werden, ohne die Lieferantenquelle der Steuerebenen- oder Datenebenenelemente der Weiterleitungselemente, wie eines Netzwerkprozessors, berücksichtigen zu müssen. In anderen Worten, der Einsatz von Steuerschnittstellen und entsprechenden APIs gemäß Ausführungsformen der vorliegenden Erfindung gestattet die Zusammenarbeit zwischen Bauteilen mehrerer Lieferanten zur Implementierung von Netzwerkelementen, um einer Mehrzahl von variierenden Netzwerkverkehrsflüssen eine verbesserte sowie variierende Dienstgüte (QoS) bereitstellen zu können.
Wenn demzufolge Netzwerk-/Routingprotokollimplementierungen in Datenebenen isoliert werden, die von Entwicklern von Drittpartei-Protokollanwendungen stammen, wird Plattform-Unabhängigkeit erzielt, die zu einer verkürzten Zeitspanne bis zur Vermarktung von Produkten, einer verbesserten Leistung und zu geringeren Kosten und größeren Innovationsmöglichkeiten führt. Des weiteren ist die bereitgestellte Steuerschnittstelle vollkommen asynchron gestaltet, um jede Art von Internet-Zusammenschaltungs-Technologie zwischen der Steuer- und Datenebene zu unterstützen. Demzufolge können Steuer- und Datenebenen mit Hilfe von Netzwerktechnologien wie zum Beispiel Ethernet-Faser verbunden werden.
Desgleichen kann die Verbindung (Zusammenschaltungs-Link) zwischen den Steuer- und Datenebenen mit Hilfe von Bustechnologie wie kompakte PCI hergestellt werden, oder die Steuer- und Datenebenen können zusammengelegt und über Interprozeßkommunikationen miteinander verbunden werden. Ferner stellen die Steuerschnittstellen eine benutzerfreundliche, skalierbare und robuste Schnittstelle zur Konfigurierung des IPv4/IPv6/MPLS/DiffServ Verhaltens in einer Netzwerkprozessor-Datenebene bereit. In einer Ausführungsform wurde zum Beispiel ein Netzwerkprozessor, wie ihn die Intel Corporation in Santa Clare, Kalifornien, herstellt, für Managementanwendungen und Routing/MPLS/QoS Anwendungen eingesetzt, die auf der Steuerebene laufen. Ferner ist es leicht, die Integration von Drittpartei-Routing-Stapeln und Managementanwendungen zu implementieren, wenn eine Steuerschnittstelle in Übereinstimmung mit Ausführungsformen der vorliegenden Erfindung eingesetzt wird.
Andere Ausführungsformen
Mehrere Aspekte einer Implementierung der Steuerschnittstelle und API zur Konfigurierung des Verhaltens mehrerer Datenebenen wurden beschrieben. Verschiedene Implementierungen der Steuerschnittstelle und API stellen jedoch zahlreiche Merkmale wie die Komplementierung, Ergänzung und/oder den Ersatz der oben beschriebenen Merkmale bereit. Merkmale können in verschiedenen Ausführungen als Teil der Steuerebene oder als Teil eines Netzwerkelements implementiert werden. Außerdem wurde in der vorangegangenen Beschreibung zum Zwecke der Erklärung ein spezifisches Benennungssystem verwendet, um ein gründliches Verständnis der erfindungsgemäßen Ausführungsformen zu ermöglichen. Für den Fachmann ist jedoch erkenntlich, daß die spezifischen Details nicht erforderlich sind, um die Ausführungsformen der Erfindung zu praktizieren.
Außerdem, obwohl sich eine hier beschriebene Ausführungsform auf eine Steuerschnittstelle und APIs für ein Netzwerkelement bezieht, wird der Fachmann erkennen, daß die Ausführungsformen der vorliegenden Erfindung auch auf andere Systeme angewandt werden können. In der Tat werden Systeme, die verschiedene Netzwerkprotokolle mit einem Netzwerkelement unterstützen, werden durch die Ausführungsformen der vorliegenden Erfindung abgedeckt, wie in den beigefügten Ansprüchen definiert. Die oben beschriebenen Ausführungsformen wurden ausgewählt und beschrieben, um die Prinzipien der Ausführungsformen der Erfindung und ihre praktischen Anwendungen auf bestmögliche Weise zu erklären. Diese Ausführungsformen wurden ausgewählt, um anderen Fachleuten zu ermöglichen, die Erfindung und verschiedene Ausführungsformen mit verschiedenen Modifikationen optimal entsprechend ihrer jeweiligen geplanten Einsatzes auszunutzen.
Es versteht sich, daß diese Offenbarung lediglich zur Veranschaulichung dient, auch wenn zahlreiche Merkmale und Vorteile verschiedener Ausführungsformen der vorliegenden Erfindung in der obigen Beschreibung zusammen mit Einzelheiten der Struktur und der Funktion verschiedener Ausführungsformen der Erfindung angeführt wurden. In manchen Fällen wurden bestimmte Unterbaugruppen im Detail ausschließlich mit Bezug auf eine solche Ausführungsform beschrieben. Trotzdem wird erkannt und beabsichtigt, solche Unterbaugruppen in anderen Ausführungsformen der Erfindung zu verwenden. Im Detail können, insbesondere an der Struktur und dem Management von Teilen, Änderungen vorgenommen werden, die innerhalb der Prinzipien der erfindungsgemäßen Ausführungsformen liegen, und die sich über das volle Ausmaß der breiten allgemeinen Bedeutung der in den beigefügten Ansprüchen verwendeten Ausdrücke erstrecken können.
Da die beispielhaften Ausführungsformen und ihre optimale Verwendungsart offenbart wurden, können Modifikationen und Änderungen an den offenbarten Ausführungsformen vorgenommen werden, ohne vom Geltungsbereich der erfindungsgemäßen Ausführungsformen, wie in den folgenden Ansprüchen definiert, abzuweichen.

Claims

Ein Verfahren, das umfaßt: Empfangen, innerhalb einer Netzwerkelement-Steuerebene, einer Protokollkonfigurationsinformation, die einer Protokollanwendung entnommen wird, die eine Netzwerkprotokollanwendungs-Programmierschnittstelle (API) verwendet; Verarbeiten der empfangenen Protokollkonfigurationsinformation unter Einsatz einer Steuerschnittstelle entsprechend einem Netzwerkprotokoll, das von der empfangenen Protokollkonfigurationsinformation angegeben wird; und Konfigurieren, durch die Steuerschnittstelle, eines oder mehrerer Datenebenen-Weiterleitungselemente des Netzwerkelements gemäß der empfangenen Protokollkonfigurationsinformation.
Verfahren nach Anspruch 1, wobei die Verarbeitung der empfangenen Protokollkonfigurationsinformation weiterhin umfaßt: Auswählen eines Weiterleitungselements innerhalb der Datenebene, um das von der Protokollkonfigurationsinformation angegebene Netzwerkprotokoll zu implementieren; Bestimmen einer oder mehrerer schnittstellenspezifischer Tabellen, die innerhalb des ausgewählten Weiterleitungselements gemäß der Protokollkonfigurationsinformation gebildet werden sollen; und Bestimmen eines oder mehrerer Einträge innerhalb der schnittstellenspezifischen Tabellen derart, daß ein die schnittstellenspezifischen Tabellen enthaltendes Weiterleitungselement Entscheidungen aufgrund der Einträge in den schnittstellenspezifischen Tabellen trifft.
Verfahren nach Anspruch 1, wobei das Konfigurieren eines oder mehrerer Datenebenen-Weiterleitungselemente weiterhin umfaßt: Anmelden des von der Protokollkonfigurationsinformation angegebenen Netzwerkprotokolls bei der Datenebene, um den Empfang von Ereignissen von der Datenebene zu ermöglichen; Auswählen eines Weiterleitungselements aus einem oder mehrereren Weiterleitungselementen einer Netzwerkelement-Datenebene; Abfragen des ausgewählten Weiterleitungselements mit Bezug auf eine oder mehrere schnittstellenspezifischen Tabellen innerhalb des ausgewählten Weiterleitungselements gemäß der Protokollkonfigurationsinformation; und Erzeugen und Erstellen eines oder mehrerer Einträge in den schnittstellenspezifischen Tabellen des ausgewählten Weiterleitungselements, um das Datenebenenverhalten zu steuern, wenn Pakete entsprechend dem von der Protokollanwendung implementierten Netzwerkprotokoll verarbeitet werden.
Verfahren nach Anspruch 3, wobei das Erzeugen weiterhin umfaßt: Abfragen des ausgewählten Weiterleitungselements, um die erzeugten schnittstellenspezifischen Tabellen zu bestimmen; und Ausfüllen der erzeugten schnittstellenspezifischen Tabellen gemäß der empfangenen Protokollkonfigurationsinformation.
Verfahren nach Anspruch 1, wobei das Konfigurieren der Datenebenenelemente weiterhin umfaßt: Anmelden des Netzwerkprotokolls bei der Netzwerkelement-Datenebene, um den Empfang von Ereignissen von der Datenebene während des Hochfahrens zu ermöglichen; Auswählen eines Weiterleitungselements innerhalb der Datenebene des Netzwerkelements, um ein IPv4-Routingprotokoll gemäß der empfangenen Protokollkonfigurationsinformation zu implementieren; Abfragen des ausgewählten Weiterleitungselements mit Bezug auf eine innerhalb des ausgewählten Weiterleitungselements während des Hochfahrens erzeugte Weiterleitungstabelle; Abfragen des ausgewählten Weiterleitungselements mit Bezug auf eine innerhalb des ausgewählten Weiterleitungselements während des Hochfahrens erzeugte Adressenermittlungstabelle; Hinzufügen/Löschen von IPv4-Routing-Einträgen innerhalb der Weiterleitungstabelle, wenn eine Aktualisierungsanforderung für eine Protokollanwendungsroute empfangen wird; und Hinzufügen/Löschen von IPv4 Einträgen innerhalb der Adressenermittlungstabelle, wenn eine Aktualisierungsanforderung für eine Protokollanwendungsadressenermittlungstabelle empfangen wird.
Verfahren nach Anspruch 1, wobei das Konfigurieren eines oder mehrerer Datenebenen-Weiterleitungselemente weiterhin umfaßt: Anmelden des Netzwerkprotokolls bei der Datenebene während des Hochfahrens, um den Empfang von Ereignissen von der Datenebene zu ermöglichen; Auswählen eines Weiterleitungselements der Datenebene des Netzwerkelements, um ein IPv6-Routingprotokoll gemäß der empfangenen Protokollkonfigurationsinformation zu implementieren; Abfragen des ausgewählten Weiterleitungselements mit Bezug auf eine innerhalb des ausgewählten Weiterleitungselements während des Hochfahrens erzeugte IPv6-Weiterleitungstabelle; Abfragen des ausgewählten Weiterleitungselements mit Bezug auf eine innerhalb des ausgewählten Weiterleitungselements während des Hochfahrens erzeugte IPv6-Nachbartabelle; Hinzufügen/Löschen von IPv6-Routing-Einträgen innerhalb der Weiterleitungstabelle, wenn eine Aktualisierungsanforderung für eine Protokollanwendungsroute empfangen wird; und Hinzufügen/Löschen von IPv6-Nachbareinträgen innerhalb der Nachbartabelle, wenn eine Aktualisierungsanforderung für eine Protokollanwendungsnachbartabelle empfangen wird.
Verfahren nach Anspruch 1, wobei das Konfigurieren eines oder mehrerer Weiterleitungselemente der Datenebene weiterhin umfaßt: Erzeugen einer FTN-Tabelle während des Hochfahrens innerhalb eines Weiterleitungselements, die zur Implementierung eines MPLS-Protokolls ausgewählt wurde; Erzeugen einer ILM-Tabelle innerhalb des ausgewählten Weiterleitungselements während des Hochfahrens; Erzeugen einer FTN DiffServ Kontexttabelle innerhalb des ausgewählten Weiterleitungselements während des Hochfahrens; Erzeugen einer ILM DiffServ Kontexttabelle innerhalb des ausgewählten Weiterleitungselements während des Hochfahrens; Hinzufügen/Löschen von MPLS FTN Einträgen in der FTN Tabelle, wenn eine Aktualisierungsanforderung für eine Protokollanwendungs-FTN-Tabelle empfangen wird; Hinzufügen/Löschen von MPLS ILM Einträgen in der ILM Tabelle, wenn eine Aktualisierungsanforderung für eine Protokollanwendungs-ILM-Tabelle empfangen wird; Hinzufügen/Löschen von MPLS E-LSP Konfigurationseinträgen in der FTN DiffServ Kontexttabelle, wenn eine Aktualisierungsanforderung für eine Protokollanwendungs-MPLS E-LSP-Konfiguration empfangen wird; und Hinzufügen/Löschen von MPLS E-LSP Vorkonfigurationseinträgen in der ILM DiffServ Kontexttabelle, wenn eine Aktualisierungsanforderung für eine Protokollanwendungs-MPLS E-LSP-Vorkonfiguration empfangen wird.
Verfahren nach Anspruch 1, wobei das Konfigurieren eines oder mehrerer Weiterleitungselemente der Datenebene weiterhin umfaßt: Erzeugen einer Mehrzahl von DiffServ Tabellen innerhalb eines Weiterleitungselements während des Hochfahrens, das zur Implementierung des DiffServ Netzwerkprotokolls ausgewählt wurde; Hinzufügen/Löschen von Filtereinträgen in einer DiffServ Classifier-Tabelle, die innerhalb des ausgewählten Weiterleitungselements erzeugt wurde, wenn eine Aktualisierungs-anforderung für einen Protokollanwendung-Classifier empfangen wurde; Hinzufügen/Löschen von „Meter”-Einträgen in einer DiffServ Meter-Tabelle, die innerhalb des ausgewählten Weiterleitungselements erzeugt wurde, wenn eine Aktualisierungsanforderung für ein Protokollanwendungs-Meter empfangen wurde; Hinzufügen/Löschen von „Marker”-Einträgen in einer DiffServ Marker-Tabelle, die innerhalb des ausgewählten Weiterleitungselements erzeugt wurde, wenn eine Aktualisierungsanforderung für einen Protokollanwendungs-Marker empfangen wurde; Hinzufügen/Löschen von „Dropper”-Einträgen in einer algorithmischen DiffServ „Dropper”-Tabelle, die innerhalb des ausgewählten Weiterleitungselements erzeugt wurde, wenn eine Aktualisierungsanforderung für einen Protokollanwendungs-Dropper empfangen wurde; Hinzufügen/Löschen von Abfrageeinträgen in einer DiffServ Warteschlangentabelle, die innerhalb des ausgewählten Weiterleitungselements erzeugt wurde, wenn eine Aktualisierungs-anforderung für eine Protokollanwendungswarteschlange empfangen wurde; und Hinzufügen/Löschen von Scheduler-Einträgen in einer DiffServ Scheduler-Tabelle, die innerhalb des ausgewählten Weiterleitungselements erzeugt wurde, wenn eine Aktualisierungs-anforderung für einen Protokollanwendungs-Scheduler empfangen wurde.
Verfahren nach Anspruch 1, weiterhin umfassend: Empfangen eines Pakets innerhalb der Datenebene; Benachrichtigen, beim Auslösen eines Ereignisses, einer Protokollanwendung, die ein dem empfangenen Paket entsprechendes Netzwerkprotokoll implementiert; andernfalls Bestimmen eines Weiterleitungselements, das mit einem oder mehreren schnittstellenspezifischen Tabellen programmiert wurde, die einem mit dem empfangenen Paket verknüpften Netzwerkprotokoll entsprechen; Benachrichtigen, beim Auslösen eines Ereignisses, einer Protokollanwendung, die ein dem empfangenen Paket entsprechendes Netzwerkprotokoll implementiert; und andernfalls Verarbeitung des empfangenen Pakets gemäß eines von der Steuerschnittstelle erzeugten schnittstellenspezifischen Tabelleneintrags entsprechend der Protokollkonfigurationsinformation und verknüpft mit dem empfangenen Paket.
Verfahren nach Anspruch 1, wobei das Netzwerkprotokoll API ein Routingprotokoll API, ein Vermittlungsprotokoll API oder ein QoS(quality-of-service)-Protokoll API ist.
Verfahren nach Anspruch 10, wobei das Routingprotokoll API ein IPv4- oder ein IPv6-Protokoll ist.
Verfahren nach Anspruch 10, wobei das Vermittlungsprotokoll API ein MPLS-Protokoll API ist.
Verfahren nach Anspruch 10, wobei das QoS-Protokoll API ein DiffServ-Protokoll API ist.
Verfahren nach Anspruch 1, wobei das Netzwerkprotokoll API Dienstgutemöglichkeiten umfaßt, um zu ermöglichen, Pakete eines bestimmten Verkehrsflusses mit einer gewünschten speziellen Handhabung zu verknüpfen.
Verfahren nach Anspruch 14, wobei die gewünschte spezielle Handhabung mindestens einen Echtzeitdienst oder eine nicht standardmäßige („non-default”) Dienstgüte umfaßt.
Ein computer-lesbares Speichermedium einschließlich Programmanweisungen an einen Computer, bei Ausführung durch einen Prozessor ein Verfahren durchzuführen, welches umfaßt: Empfangen, innerhalb einer Netzwerkelement-Steuerebene, einer Protokollkonfigurationsinformation, die einer Protokollanwendung entnommen wird, die eine Netzwerkprotokollanwendungs-Programmierschnittstelle (API) verwendet; Verarbeiten der empfangenen Protokollkonfigurationsinformation unter Einsatz einer Steuerschnittstelle entsprechend einem Netzwerkprotokoll, das von der empfangenen Protokollkonfigurationsinformation angegeben wird; und Konfigurieren, durch die Steuerschnittstelle, eines oder mehrerer Datenebenen-Weiterleitungselemente des Netzwerkelements gemäß der empfangenen Protokollkonfigurationsinformation.
Computer-lesbares Speichermedium nach Anspruch 16, wobei das Verarbeiten der empfangenen Software ferner umfaßt: Auswählen eines Weiterleitungselements innerhalb der Datenebene zur Implementierung des von der Protokollkonfigurationsinformation angegebenen Netzwerkprotokolls; Bestimmen einer oder mehrerer innerhalb des ausgewählten Weiterleitungselements zu bildender schnittstellenspezifischer Tabellen gemäß der Protokollkonfigurationsinformation; und Bestimmen eines oder mehrerer Einträge innerhalb der schnittstellenspezifischen Tabellen derart, daß ein die schnittstellenspezifischen Tabellen enthaltendes Weiterleitungselement Entscheidungen entsprechend den Einträgen innerhalb der schnittstellenspezifischen Tabellen trifft.
Computer-lesbares Speichermedium nach Anspruch 16, wobei das Konfigurieren eines oder mehrerer der Datenebenen-Weiterleitungselemente ferner umfaßt: Anmelden des von der Protokollkonfigurationsinformation angegebenen Netzwerkprotokolls bei der Datenebene, um den Empfang von Ereignisse von der Datenebene während des Hochfahrens zu ermöglichen; Auswählen eines Weiterleitungselements aus einem oder mehreren Weiterleitungselementen einer Netzwerkelement-Datenebene; Abfragen des ausgewählten Weiterleitungselements mit Bezug auf eine oder mehrere schnittstellenspezifischen Tabellen innerhalb des ausgewählten Weiterleitungselements entsprechend der Protokollkonfigurationsinformation; und Erzeugen und Erstellen eines oder mehrerer Einträge innerhalb der schnittstellenspezifischen Tabellen des ausgewählten Weiterleitungselements, um das Datenebenenverhalten zu steuern, wenn Pakete entsprechend dem von der Protokollanwendung implementierten Netzwerkprotokoll verarbeitet werden.
Computer-lesbares Speichermedium nach Anspruch 16, wobei das Verfahren ferner umfaßt: Empfangen eines Pakets innerhalb der Datenebene; Benachrichtigen, beim Auslösen eines Ereignisses, einer Protokollanwendung, die ein dem empfangenen Paket entsprechendes Netzwerkprotokoll implementiert; andernfalls Bestimmen eines Weiterleitungselements, das mit einem oder mehreren schnittstellenspezifischen Tabellen programmiert wurde, die einem mit dem empfangenen Paket verknüpften Netzwerkprotokoll entsprechen; Benachrichtigen, beim Auslösen eines Ereignisses, einer Protokollanwendung, die ein dem empfangenen Paket entsprechendes Netzwerkprotokoll implementiert; und andernfalls Verarbeitung des empfangenen Pakets gemäß eines von der Steuerschnittstelle erzeugten schnittstellenspezifischen Tabelleneintrags entsprechend der Protokollkonfigurationsinformation und verknüpft mit dem empfangenen Paket.
Verfahren nach Anspruch 16, wobei das Netzwerkprotokoll API ein Routingprotokoll API ein Vermittlungsprotokoll API oder ein QoS(quality-of-service)-Protokoll API ist.
Verfahren nach Anspruch 20, wobei das Routingprotokoll API ein IPv4- oder ein IPv6-Protokoll ist.
Verfahren nach Anspruch 20, wobei das Vermittlungsprotokoll API ein MPLS-Protokoll API ist.
Verfahren nach Anspruch 20, wobei das QoS-Protokoll API ein DiffServ-Protokoll API ist.
Verfahren nach Anspruch 16, wobei das Netzwerkprotokoll API Dienstgütemöglichkeiten umfaßt, um zu ermöglichen, Pakete eines bestimmten Verkehrsflusses mit einer gewünschten speziellen Handhabung zu verknüpfen.
Verfahren nach Anspruch 24, wobei die gewünschte spezielle Handhabung mindestens einen Echtzeit-Dienst oder eine nicht standardmäßige („non-default”) Dienstgüte umfaßt.
Ein Netzwerkelement, umfassend: eine Datenebene einschließlich eines oder mehrerer Weiterleitungselemente, um Pakete gemäß einer entsprechenden schnittstellenspezifischen Tabelle innerhalb eines entsprechenden Weiterleitungselements zu verarbeiten; eine Steuerebene, die mit der Datenebene über eine Zusammenschaltungs-Link verbunden ist, wobei die Steuerebene eine oder mehrere Protokollanwendungen enthält, die mit Hilfe einer Programmierschnittstelle (API) einer Netzwerkprotokollanwendung Netzwerkprotokolle implementieren; und eine Steuerschnittstelle, die zum Erzeugen und Konfigurieren von schnittstellenspezifischen Tabellen innerhalb der Datenebene entsprechend der Protokollkonfigurationsinformation, die den Protokollanwendungen der Steuerebene durch eine entsprechende Protokoll API entnommen wird, verwendet wird.
Netzwerkelement nach Anspruch 26, wobei die Steuerschnittstelle ferner veranlaßt: die Auswahl eines Weiterleitungselements innerhalb der Datenebene, um das von der Protokollkonfigurationsinformation angegebene Netzwerkprotokoll zu implementieren; die Bestimmung einer oder mehrerer schnittstellenspezifischen Tabellen, die innerhalb des ausgewählten Weiterleitungselements gemäß der Protokollkonfigurationsinformation zu bilden sind; und die Bestimmung, gemäß der Protokollkonfigurationsinformation, von einem oder mehreren Einträgen innerhalb der schnittstellenspezifischen Tabellen, derart, daß ein die schnittstellenspezifischen Tabellen enthaltendes Weiterleitungselement Protokollentscheidungen gemäß den Einträgen innerhalb der schnittstellenspezifischen Tabellen trifft.
Netzwerkelement nach Anspruch 26, wobei die Steuerschnittstelle ferner veranlaßt: Anmelden des von der Protokollkonfigurationsinformation angegebenen Netzwerkprotokolls bei der Datenebene, um den Empfang von Ereignissen von der Datenebene während des Hochfahrens zu ermöglichen; Auswählen eines Weiterleitungselements aus einem oder mehreren Weiterleitungselementen einer Netzwerkelement-Datenebene; Abfragen des ausgewählten Weiterleitungselements mit Bezug auf eine oder mehrere schnittstellenspezifischen Tabellen, die während des Hochfahrens innerhalb des ausgewählten Weiterleitungselements erzeugt werden; und Erzeugen und Erstellen eines oder mehrerer Einträge innerhalb der schnittstellenspezifischen Tabellen des ausgewählten Weiterleitungselements entsprechend der entnommenen Protokollkonfigurationsinformation.
Netzwerkelement nach Anspruch 26, wobei die Steuerschnittstelle ferner veranlaßt: den Empfang eines Pakets innerhalb der Datenebene; die Bestimmung eines Weiterleitungselements, das mit einer oder mehreren schnittstellenspezifischen Tabellen programmiert wurde, die einem mit dem Paket verknüpften Netzwerkprotokoll entsprechen; die Verarbeitung des Pakets gemäß eines von der Steuerschnittstelle erzeugten schnittstellenspezifischen Tabelleneintrags entsprechend der empfangenen Protokollkonfigurationsinformation; und bei Auslösung eines Ereignisses das Benachrichtigen der Protokollanwendung, die ein mit dem Paket verknüpftes Netzwerkprotokoll implementiert.
Netzwerkelement nach Anspruch 26, wobei die Zusammenschaltungs-Link ein Bus, ein Kabel, eine optische Faser oder eine Ethernet-Link ist.
Ein System umfaßt: ein Netzwerk mit einer Mehrzahl von gekoppelten Netzwerkelementen, umfassend: eine Datenebene mit einem oder mehreren Weiterleitungselementen, um das empfangene Paket gemäß einer entsprechenden schnittstellenspezifischen Tabelle innerhalb eines entsprechenden Weiterleitungselements zu verarbeiten; eine Steuerebene, die über eine Zusammenschaltungs-Link mit der Datenebene gekoppelt ist, wobei die Steuerebene eine oder mehrere Protokollanwendungen umfaßt, die Netzwerkprotokolle mit Hilfe einer Programmierschnittstelle (API) von Netzwerkprotokollanwendungen implementieren; und eine Steuerschnittstelle, die zum Erzeugen und Konfigurieren der schnittstellenspezifischen Tabellen innerhalb der Datenebene entsprechend der Protokollkonfigurationsinformation verwendet wird, die den Protokollanwendungen der Steuerebene durch ein entsprechendes Protokoll API entnommen wird.
System nach Anspruch 31, wobei die Steuerschnittstelle ferner veranlaßt: die Auswahl eines Weiterleitungselements innerhalb der Datenebene, um das von der Protokollkonfigurationsinformation angegebene Netzwerkprotokoll zu implementieren; die Bestimmung einer oder mehrerer schnittstellenspezifischer Tabellen, die innerhalb des ausgewählten Weiterleitungselements entsprechend der Protokollkonfigurationsinformation zu bilden sind; und die Bestimmung, gemäß der Protokollkonfigurationsinformation, von einem oder mehreren Einträgen innerhalb der schnittstellenspezifischen Tabellen, derart, daß ein die schnittstellenspezifischen Tabellen enthaltendes Weiterleitungselement Protokollentscheidungen gemäß den Einträgen innerhalb der schnittstellenspezifischen Tabellen trifft.
Netzwerkelement nach Anspruch 31, wobei die Steuerschnittstelle ferner veranlaßt: das Anmelden des von der Protokollkonfigurationsinformation angegebenen Netzwerkprotokolls bei der Datenebene, um den Empfang von Ereignissen von der Datenebene während des Hochfahrens zu ermöglichen; das Auswählen eines Weiterleitungselements aus einem oder mehreren Weiterleitungselementen einer Netzwerkelement-Datenebene; das Abfragen des ausgewählten Weiterleitungselements mit Bezug auf eine oder mehrere schnittstellenspezifischen Tabellen, die während des Hochfahrens innerhalb des ausgewählten Weiterleitungselements erzeugt werden; und das Erzeugen und Erstellen eines oder mehrerer Einträge innerhalb der schnittstellenspezifischen Tabellen des ausgewählten Weiterleitungselements gemäß der entnommenen Protokollkonfigurationsinformation.
Netzwerkelement nach Anspruch 31, wobei die Steuerschnittstelle ferner veranlaßt: den Empfang eines Pakets innerhalb der Datenebene; die Bestimmung eines Weiterleitungselements, das mit einer oder mehreren schnittstellenspezifischen Tabellen entsprechend einem mit dem Paket verknüpften Netzwerkprotokoll programmiert wurde; die Verarbeitung des Pakets gemäß eines von der Steuerschnittstelle erzeugten schnittstellenspezifischen Tabelleneintrags entsprechend der empfangenen Protokollkonfigurationsinformation; und bei Auslösung eines Ereignisses das Benachrichtigen der Protokollanwendung, die ein mit dem Paket verknüpftes Netzwerkprotokoll implementiert.
Netzwerkelement nach Anspruch 26, wobei die Zusammenschaltungs-Link ein Bus, ein Kabel, eine optische Faser oder eine Ethernet-Link ist.