-
Die
Erfindung betrifft ein Verfahren nach den Oberbegriffen der Ansprüche 1, 3,
5 und 7.
-
Zukünftig werden
Internet-Protokoll-Netze, kurz IP-Netze, neben den heute üblichen
Internet- und Best-effort-Diensten auch höherwertige Qualitätsdienste
transportieren und neue Anwendungen erlauben. Dazu sind Erweiterungen
der Steuerung der Netzknoten eines IP-Netzes bzw. der Netzsteuerung
nötig,
z.B. zur Verwaltung der Netzressourcen oder für schnelle Rekonfigurationen
im Fehlerfall.
-
Generell
gibt es die Alternativen:
- • Steuerkomponenten in die Netzkomponenten, Netzknoten
und/oder Netzelemente, wie Router, zu integrieren oder
- • Steuerkomponenten
als externe Server an die zu steuernden Netzkomponenten, Netzknoten bzw.
Router anzubinden. Dies kann direkt, d.h. durch eine Verbindung
oder Leitung zwischen einer externen Schnittstelle der Netzkomponente und
der in der Nähe
befindlichen Steuerkomponente, oder über eine Netzverbindung zwischen Netzkomponente
und Steuerkomponente erfolgen.
-
Die
erste integrierte Lösung
hat den Vorteil, dass der Steuerkomponente durch die enge Kopplung
zur Netzkomponente interne Informationen der Netzkomponente zur
Verfügung
stehen.
-
Demgegenüber ist
eine "beigestellte" Lösung herstellerunabhängig und
flexibler, da sie gerade nicht so eng mit den Interna der Netzkomponente verwoben
ist. Darüber
hinaus können "beigestellte" Lösungen auf
standardisierten Hardware-, kurz HW, und Software-, kurz SW, Lösungen basieren,
während Netzkomponenten,
wie Router, meist auf proprietären
HW/SW-Lösungen basieren.
Durch "beigestellte" Steuerkomponenten
lassen sich kürzere
Entwicklungszyklen und Kosteneinsparungen erreichen. Der Nachteil "beigestellter" Lösungen besteht
darin, dass interne Informationen der Netzkomponente nicht zur Verfügung stehen.
-
Am
Beispiel einer Admission Control-, kurz AC, Steuerkomponente soll
im folgenden die Problematik der zweiten, externen, "beigestellten" Server-Lösung dargestellt
werden.
-
Eine
Aufgabe einer Admission Control besteht darin, ankommende Ressourcen
Anfragen entgegenzunehmen, diese mit den noch verfügbaren Ressourcen
abzugleichen und bei noch verfügbaren Ressourcen
einen Netzknoten bzw. Router, z.B. den Router am Netzrand respektive
Edge-Router für
die Kontrolle des Datenflusses zu programmieren. Dies umfasst die
Einstellung von sogenannten Funktionen, wie marking, filtering und
policing.
-
Dabei
treten u.a. die folgenden zwei Fragestellungen auf:
- A) Wie erreichen die Ressourcen-Anfragen die beigestellte Steuerungskomponente
bzw. Admission Control?
- B) Wie kann die Steuerungskomponente bzw. Admission Control
den Netzknoten steuern und konfigurieren und woher bezieht die Steuerungskomponente
die nötigen
Informationen über
die Interna der Netzkomponente, z.B. an welchem Interface ist ein
Paket empfangen worden und welches Interface ist zu konfigurieren?
-
Zu
A) existieren im Prinzip zwei Lösungsvarianten:
- 1) Der Datenpfad, den die IP Pakete nehmen,
ist bekannt und entsprechend kann die Steuerungskomponente bzw.
Admission Control direkt adressiert werden. Dies wird als sogenannte
Out-Band Signalisierung bezeichnet.
- 2) Das Signalisierungsprotokoll folgt dem Pfad der Datenpakete
und findet so die Steuerungskomponente bzw. Admission Control automatisch.
Dies wird als sogenannte In-Band Signalisierung bezeichnet.
-
Im
folgenden wird ausschließlich
von der Signalisierung nach Variante 2) ausgegangen, also der In-Band
Signalisierung.
-
Das
standardisierte Ressourcen Reservierungs-Protokoll RSVP ist ein
In-Band Signalisierungsprotokoll. Es löst die oben aufgezeigte Fragestellungen
wie unter Punkt 2) beschrieben und führt eine Hop-by-Hop Reservierung
im Netzknoten durch. Kernpunkt dabei ist, dass die RSVP-Instanz
im Router selbst implementiert wird und daher sehr eng mit dem Router
und seinen Interna verzahnt operieren kann.
-
Am
Beispiel eines RSVP-fähigen
Netzes, d.h. eines Netzes mit RSVP-fähigen Netzknoten bzw. Routern
gemäß 1 soll schematisch der Ablauf beschrieben
werden.
-
1 zeigt ein schematisches
IP Netz, bestehend aus mehreren Netzknoten bzw. Routern A bis H,
die intern jeweils eine Steuerkomponente AC aufweisen. Der Netzknoten
A ist einerseits durch eine Serienschaltung der Netzknoten B, C,
D und andererseits durch eine Serienschaltung der Netzknoten F, G,
H mit dem Netzknoten E verbunden. Die Netzknoten B und G, C und
H sowie D und H sind ebenfalls untereinander verbunden. Die Verbindungen
bzw. Verbindungswege sind bspw. als elektrische oder optische Leitungen
ausgeführt,
wie Zweidrahtleitungen, Koaxialkabel oder Lichtwellenleiter. Am
Netzknoten A ist ein Teilnehmer X angeschlossen und am Netzknoten
E ist ein Teilnehmer Y angeschlossen.
-
Der
Teilnehmer X erzeugt eine Ressourcen-Anforderung an das Netz für einen
Datenstrom zu Teilnehmer Y. Dabei muss sichergestellt werden, dass
die Ressourcen-Reservierungen in den Netzknoten auch tatsächlich entlang
des späteren
Datenpfades vorgenommen werden. In IP-Netzen hängt dieser Datenpfad vom aktuellen
Routing ab. Daher wird im Ressourcen Reservierungs- Protokoll RSVP die
Ressourcen-Anforderung mit der IP Zieladresse, also der IP-Adresse
des Teilnehmers Y, in das Netz gesendet. Sie folgt damit automatisch
dem Datenpfad des späteren
Datenstroms zu Teilnehmer Y. Obwohl diese RSVP-Nachrichten ja nun nicht an die RSVP-Steuerungskomponenten
AC bzw. RSVP-Instanzen adressiert sind, müssen die RSVP-Steuerungskomponenten
AC bzw. RSVP-Instanzen der auf dem Weg liegenden Netzknoten jeweils
Kenntnis davon erhalten.
-
Daher
sind diese Nachrichten durch den definierten IP-Protokoll-Typ "RSVP" im
IP Header, also im Kopf eines IP-Paketes,
speziell gekennzeichnet.
-
Die
Router erkennen diesen Protokolltyp und geben solchermaßen gekennzeichnete
Nachrichten direkt an ihre RSVP-Instanz weiter, also an die Steuerkomponente
AC.
-
Später, im
Verlauf der Prozedur, muss die RSVP-Instanz am Netzrand zum Teilnehmer
X "ihren" Edge-Router A konfigurieren
(filtering, marking, policing). Konkret ist dasjenige Interface
zu konfigurieren, über
das die RSVP-Nachricht vom Teilnehmer X ursprünglich eingetroffen war und über das
später der
Datenstrom von Teilnehmer X zu Teilnehmer Y eintreffen wird. Da
die RSVP-Instanz im Router implementiert ist, kann sie diese internen
Informationen abfragen.
-
Die
Lösung
für die
beiden Punkte A und B liegt hier in der engen internen Kopplung
zwischen Netzknoten und Steuerkomponente.
- Zu
A) Die Ressourcen-Anfragen erreichen die Steuerkomponente über spezielle
Filter im Netzknoten bzw. Router, welche die Protokoll-ID erkennen
und die Pakete am Routing vorbei direkt an die interne Steuerkomponente
weiterleiten.
- Zu B) Information zur Konfiguration des Netzknotens bzw. Routers
erhält
die Steuerungskomponente AC durch Zugriff auf routerinterne Daten.
-
Bei
externen Steuerungskomponenten besteht das Problem, dass diese internen
Informationen nicht beim Netzknoten abgefragt bzw. vom Netzknoten
zur Verfügung
gestellt werden. Ein weiteres Problem existiert, wenn die externen
Steuerungskomponenten des Netzknotens nicht direkt diesem beigestellt
sind, sondern sich an einer weit entfernten Stelle des Netzes befinden
und nur über
eine Netzwerkverbindung erreichbar sind.
-
Aufgabe
der vorliegenden Erfindung ist es, ein Verfahren anzugeben, bei
dem empfangene IP-Pakete mit Interface Informationen des empfangenden
Netzknoten an eine externe Steuerkomponente weitergegeben werden
können.
-
Diese
Aufgabe wird durch Verfahren gemäß den Merkmalen
der Ansprüche
1, 3, 5 oder 7 gelöst.
-
Der
Vorteil der Erfindung besteht darin, dass IP Pakete mit netzknoteninternen
Steuerinformationen an eine externe Steuerungskomponente weitergeleitet
werden. Dadurch kann eine einem Netzknoten "beigestellte" Steuerungskomponente umfangreichere
Steuerungsaufgaben des Netzknotens übernehmen.
-
Ein
weiterer Vorteil besteht darin, dass die externe Steuerungskomponente
an einer entfernten Stelle des Netzes angeordnet sein kann und über eine
Netzwerkverbindung angeschlossen ist.
-
Vorteilhafte
Weiterbildungen der Erfindung sind in den Unteransprüchen angegeben.
-
Ein
Ausführungsbeispiel
der Erfindung ist in der Zeichnung dargestellt und wird im folgenden
erläutert.
-
Dabei
zeigt:
-
1 ein schematisches IP-Netz
mit netzknoteninternen Steuerkomponenten AC gemäß dem Stand der Technik.
-
2 ein gemäß 1 analog aufgebautes IP-
Netz mit zwei externen Steuerkomponenten AC gemäß der Erfindung.
-
Die 1 zeigt ein bereits in der
Beschreibungseinleitung erläutertes
IP-Netz gemäß dem Stand
der Technik.
-
Die 2 zeigt ein Netz gemäß 1, mit dem Unterschied,
dass jeweils eine externe Steuerungskomponente AC an den Netzelementen
D und G angeschlossen ist.
-
Analog
dem in der Beschreibungseinleitung genannten Beispiel sollen Datenpakete
vom Teilnehmer X zum Teilnehmer Y übertragen werden. Dabei benötigen die
externen Steuerungskomponenten AC bestimmte IP-Pakete, wie In-Band
IP Signalisierungspakete, beispielsweise RSVP-Pakete, und die Information,
an welchem Interface des Netzknotens das IP-Paket / In-Band IP Signalisierungspaket
/ RSVP-Paket empfangen wurde. Letztere Information ist nur intern
im Netzknoten verfügbar
und kann nicht abgefragt werden. Die Routingtabellen des Netzknotens
bzw. Routers enthalten nur Informationen über Ziele, jedoch nicht darüber, woher
ein Paket kam.
-
Um
das Problem zu lösen
werden auf den Interfaces der Netzknoten Regeln konfiguriert. Aktuelle Netzknoten
bzw. Router unterstützen
sogenanntes Policy-Routing. Dabei können Regeln konfiguriert werden,
wie mit speziellen Paketen zu verfahren ist. Zudem wird das sogenannte
Tunneling verwendet.
-
Durch
IP-Tunnel, z.B. GRE-Tunnel, wird das originale IP Paket am Tunneleingang
um einen Tunnelheader inklusive einer Tunnel-ID und einem neuen äußeren IP
Header ergänzt.
Mit diesem IP-Header wird das IP-Paket durch das Netz gerouted.
Am Tunnelendpunkt wird der äußere Header
wieder entfernt und das Original-Paket weiter bearbeitet.
-
Moderne
Netzknoten bzw. Router, insbesondere die hier betroffenen Edge Router,
unterstützen oftmals
eine oder mehrere Varianten des Tunneling.
-
Die
Lösung
mit Tunneln beruht darauf, dass mehrere Tunnels vom Netzknoten bzw.
Router (Tunnelbeginn) zu der Steuerungskomponente AC bzw. Steuerinstanz
(Endpunkt) eingerichtet werden, die durch ihre Tunnel-Identifikationsnummer,
kurz Tunnel-ID, im Tunnel-Header unterschieden werden.
-
Eine
erste Variante beruht darauf, die Tunnel-ID zur Übertragung interner Information
zu verwenden. So wird pro Interface des Netzknotens ein eigener
Tunnel zur Steuerungskomponente eingerichtet, so dass die Interface-Nummer
explizit oder implizit der Tunnel-ID entspricht.
-
Hierzu
wird von jeder Schnittstelle des Netzknotens ein Tunnel zur Steuerungskomponente
eingerichtet. Dazu wird eine Regel im Netzknoten oder auf der Schnittstelle
eingerichtet, dass bestimmte IP-Pakete, wie In-Band IP Signalisierungspakete,
die durch einen Eintrag im Protokollfeld des IP-Headers des IP-Paketes
gekennzeichnet sind, in einem zweiten, "äußeren" IP-Paket eingepackt
werden, die IP-Adresse der dem Netzknoten zugeordneten Steuerungskomponente
als Ziel-IP-Adresse in das "äußere" IP-Paket eingetragen
wird und ein dem Interface zugeordneter eindeutiger Wert, der sich
von den Werten der anderen Interfaces des Netzknoten unterscheidet
und mit dem das Interface eindeutig erkannt werden kann, als Tunnel-ID in das "äußere" IP-Paket eingetragen. Dieses Paket
wird durch das IP-Routing an die Steuerungskomponente weitergeleitet.
Analog werden In-Band IP Signalisierungspakete des Typs „RSVP" eingepackt und übertragen.
-
Durch
diese Tunnel-Lösung
entsteht der Vorteil, dass die Steuerungskomponenten bzw. Steuerinstanzen
nicht direkt an den Netzknoten bzw. Router angebunden sein müssen, sondern
irgendwo in das Netz gestellt werden können, wie in 2 beispielhaft durch die Steuerungskomponenten
AC an den Netzknoten D und G dargestellt. Die Steuerungskomponenten
AC sind dann über
die logische "Direkt-Schnittstelle" Tunnel erreichbar.
-
In
einer parallelen Patentanmeldung der Anmelderin wird für eine ähnliche
Aufgabe eine Lösung durch
das sogenannte DSCP-Marking
vorgeschlagen. Dabei wird bei einem bestimmten empfangenen IP-Paket,
wie ein In-Band IP Signalisierungspaket des Typs „RSVP", der Wert eines
bestimmten Feldes, wie des DSCP-Feldes, des IP-Headers bzw. Kopffeldes
des IP-Paketes verändert
und ein von der empfangenden Schnittstelle des Netzknotens abhängiger Wert
in das bestimmte Kopffeld / DSCP-Feld
eingetragen. Diese Lösung
lässt sich
mit der Tunnel-Lösung kombinieren.
So können
Tunnel eingerichtet werden und zusätzlich können die DSCP Felder eines
IP-Paketes modifiziert werden.
-
Die
Regeln auf den Interfaces der Netzknoten enthalten dann ein entsprechendes
Marking, wie DSCP-Marking, und als "next-hop" Eintrag den entsprechenden
Tunnel.
-
Im
folgenden wird als zu veränderndes
Feld das DSCP-Feld angenommen, es kann aber auch ein anderes Feld
im Header bzw. Kopf des IP-Paketes verwendet werden.
-
Wird
DSCP-Marking und Tunneling verwendet, sollte eine DSCP-Feld Veränderung
bzw. ein DSCP-Marking auf dem inneren IP-Header vorgenommen werden. Der äußeren IP-Header
kann dann wirklich zur DSCP Prioritätskennzeichnung verwendet werden.
-
Zudem
muss die Tunnel-ID nicht mehr einen der Schnittstelle zugeordneten
Wert enthalten, da dieser eindeutig in das DSCP-Feld eingetragen wird.
-
Außerdem muss
nicht von jeder Schnittstelle des Netzknotens ein Tunnel zur zugeordneten
Steuerungskomponente eingerichtet werden. So könnte vom Netzknoten mindestens
ein Tunnel zur Steuerungskomponente eingerichtet werden, wobei alle IP-Pakete eines bestimmten
Typs, wie In-Band IP Signalisierungspakete, z.B. „RSVP"-Pakete, zur Steuerungskomponente übertragen
werden und die Unterscheidung, an welcher Schnittstelle das Paket
empfangen wurde, durch das veränderte
DSCP Feld erfolgt.
-
Da
das DSCP Feld 6 Bit groß ist,
was einen Bereich von 64 Werten erlaubt, wird durch eine Kombination
von Tunneling und DSCP-Marking der verfügbare Wertebereich erhöht. Dadurch
kann mit wenig Tunneln ein großer
Bereich abgedeckt werden. Durch z.B. 2 Tunnel und DSCP-Marking lassen
sich so 128 Werte bzw. Schnittstellen respektive Interfaces des
Netzknotens unterscheiden.
-
Ein
Tunneling lässt
sich ebenfalls durch Multi Protocol Label Switching, kurz MPLS,
erreichen. Das Verfahren arbeitet analog zu IP-Tunneln, mit dem
Unterschied, dass an Stelle der IP-Tunnel MPLS-"Tunnels" beziehungsweise MPLS-Pfade eingesetzt
werden.
-
Beim
Multiprotocol Label Switching, kurz MPLS, werden netzweit Zustände gehalten,
welche die Wege bzw. Pfade definieren, auf denen Pakete unter Umgehung
des "normalen" IP-Routing durch das
Netz geleitet werden. Die Netzknoten leiten dabei Pakete nicht mehr
anhand der Ziel-IP-Adressen weiter, sondern es wird jedem Paket
am Netzeingang eine Bitfolge, ein sogenanntes Label, beigefügt. Dieses
Label, das in jedem Netzknoten ausgewertet wird, bestimmt, auf welchem
Weg die Pakete weitergeleitet werden. Der Zusammenhang zwischen
Labels und Pfaden muss bei der Inbetriebnahme des Netzes hergestellt
werden. Das Label wird am Netzausgang wieder entfernt. Außerdem werden örtlich bzw.
lokal Mechanismen bzw. Regeln benötigt, um Pakete auf einen Ersatzpfad
umzulenken, wenn der ursprünglich
vorgesehene Pfad ausfällt,
oder um einen Ersatzpfad nach einem Ausfall aufzubauen.
-
Dabei
wird ein an einer Schnittstelle des Netzknotens empfangenes In-Band
IP Signalisierungspaket bzw. ein IP-Paket des Typs „RSVP", oder auch eines
anderen Typs, erkannt und dem Paket ein MPLS-Label vorangestellt,
dessen Label-ID ist eineindeutig der empfangenden Schnittstelle
zugeordnet und führt
zu der dem Netzknoten zugeordneten Steuerungskomponente. Das derart
eingepackte IP-Paket wird mittels MPLS zur Steuerungskomponente
weitergeleitet. Die dem IP-Paket vorangestellte MPLS-Label-ID wird
in der Steuerungskomponente ausgewertet und aus einem Vergleich
mit gespeicherten Werten wird in der Steuerungskomponente die Schnittstelle
bzw. das Interface ermittelt, auf dem das IP-Paket vom Netzknoten
empfangen wurde.
-
Auf
dem Interface des Netzknotens wird die Regel implementiert, dass
ein bestimmter, für
das Interface fest definierter Wert als MPLS-Label dem IP-Paket
vorangestellt wird und das Paket durch MPLS weitergeleitet wird.
Durch das MPLS-Verfahren
muss sichergestellt werden, dass Pakete mit einer bestimmten MPLS-Label-ID
zu den entsprechenden Zielen führen,
im Beispiel zur Steuerungskomponente.
-
Auch
in diesem Fall kann MPLS mit DSCP-Marking, analog dem vorher geschriebenen Verfahren,
kombiniert werden. Dabei reicht es, wenn im Netzknoten mindestens
eine MPLS-Label-ID eingtragen wird, da die Unterscheidung der Schnittstellen des
Netzknotens durch das DSCP-Marking erfolgt.
-
Beispielsweise
wird ein an einer Schnittstelle des Netzknotens empfangenes In-Band
IP Signalisierungspaket bzw. ein Paket des Typs "RSVP" erkannt
und derart verarbeitet, dass der Wert eines bestimmten Feldes, wie
des "DSCP" Feldes, in Abhängigkeit
von der empfangenden Schnittstelle verändert wird. Zum Beispiel wird
eine eindeutige Schnittstellen-ID, die sich von den Schnittstellen-ID
der anderen Schnittstellen des Netzknotens unterscheidet, in das
DSCP-Feld eingetragen, ferner dem IP-Paket ein MPLS-Label vorangestellt
und dieses ver änderte Paket
durch das MPLS-Verfahren an die Steuerkomponente weitergeleitet.
Hierbei muss nicht jede Schnittstelle eine eigene MPLS-Label-ID
eintragen, da die Unterscheidung der Schnittstellen respektive Interfaces
durch das DSCP-Feld erfolgt. Ebenso lassen sich durch Kombination
von MPLS-Label-ID und dem DSCP-Marking große Wertebereiche erreichen. Durch
z.B. 2 MPLS-Label-ID und DSCP-Marking lassen sich 128 Werte bzw.
Schnittstellen eines Netzknotens unterscheiden.