-
Der
Anmeldungsgegenstand betrifft ein Verfahren zur Ratenbegrenzung
in einem Pakete nach dem Internet-Protokoll transportierenden Netz.
-
Wenn
in einem Netz mit verbindungsloser Paketvermittlung (z.B. IP (InternetProtocol)-Netz) QoS(Quality
of Service)-Zusagen
abgegeben werden sollen, muss immer auch sichergestellt werden, dass
der tatsächlich
ins Netz eingelassene Verkehr nicht mehr ist als der bei einer Ressourcensteuerung angemeldete
Verkehr. Dazu werden Ratenbegrenzungseinheiten (Policer) eingesetzt,
die z.B. in jedem Router oder an jedem Router des Netzeingangs überprüfen, ob
der eingelassene Verkehr einer vorgegebenen Verkehrsbeschreibung
(z.B. maximale Bitrate, mittlere Bitrate und jeweils eine Burst-Toleranz
dazu für
einen dual leaky bucket policer) entspricht. Wenn mehr Verkehr gesendet
wird als nach der Beschreibung zulässig wäre, werden die entsprechenden
Pakete entweder verworfen oder ummarkiert, so dass sie bei Ressourcenknappheit
als erste verworfen werden, damit insgesamt die Dienstgüte für alle zugelassenen
Verkehrsströme
gewährleistet werden
kann.
-
Die
Policer-Einheiten werden aus Performance-Gründen in Hardware realisiert.
Daher kann pro Router-Interface nur eine maximale Anzahl solcher
Policer gleichzeitig aktiviert werden (beim Juniper ERX1400 z.B.
ca. 100). Andererseits gibt es in einem Netz sehr viele Verkehrsflüsse von
unterschiedlichen Quellen zu unterschiedlichen Zielen. Die von einem
Policer zu beachtenden Pakete werden i.d.R. durch Regeln definiert.
Dabei kann z.B. eine Definition von Ursprungs- und Zieladresse (Host-Adresse oder
Netz-Adresse mit zusätzlich
angegebener Prefix-Läge)
des Paketes herangezogen werden oder eine Verknüpfung aus mehreren solchen
Definitionen.
-
In
der Praxis stellt sich das Problem, dass – bei begrenzten Lebensdauern
der entsprechenden Reservierungen – sehr viele Reservierungen
in kurzer Zeit auf- und abgebaut werden müssen und entsprechend auch
die Policer sehr häufig
umkonfiguriert werden müssen;
Rechenbeispiel: Ein Router-Interface mit 10Gbit/s kann ca. 100000
Telefongespräche à 100kbit/s
gleichzeitig tragen. Wenn jedes dieser Telefongespräche im Mittel
ca. 200 Sekunden dauert, müssen
ca. 500 Reservierungen pro Sekunde auf- und ebenso viele abgebaut
werden, so dass insgesamt ca. 1000 Konfigurationen pro Sekunde nötig sind – ganz abgesehen
von der Notwendigkeit, pro Interface 100000 Policer in Hardware
bereitzustellen.
-
Daher
möchte
man in der Praxis die Reservierungen aggregieren. Dazu werden eine
Reihe von Einzel-Reservierungen zusammengefasst und es wird im Netz
nur eine gemeinsame Reservierung für alle entsprechenden Verkehrsströme durchgeführt. Wenn
für diese
Sammel-Reservierung gleich mehr Bitrate belegt wird als die bereits
vorhandenen Verkehrsströme
erfordern, können
weiter Verkehrsströme
in die Reservierung aufgenommen werden, ohne dass im Netz etwas
umkonfiguriert werden muss.
-
Herkömmlich gibt
es keine Konfigurationsoptionen in den Routern, um den von einer
solchen Sammel-Reservierung erfassten Paketverkehr so zu beschreiben,
dass die Konfiguration des Policers nicht immer wieder für eine Einzel-Reservierung
geändert
werden muss. Die einzige mit heutigen Mitteln mögliche Aggregat-Konfiguration
bezieht sich auf einen gemeinsamen Zielnetz-Prefix, d.h. sie erfasst alle
Pakete, deren Ziel-IP-Adressen
mit denselben n Bits beginnen, wobei die Werte dieser Bits und die Anzahl
in Form einer Netzadresse vorgegeben werden. Im heutigen Internet
ist allerdings aus verschiedenen Gründen der IP-Adressraum nicht
so strukturiert, dass die IP-Adressen
leicht zu übergeordneten Netz-Adressen
(Prefixes) zusammengefasst werden könnten. Dies soll durch einen
Ausschnitt aus der Zuordnung der Class-B-Prefixes im Bereich 129.*/16
in 1 verdeutlicht werden.
-
Es
ist zu erkennen, dass es keinen Zusammenhang zwischen aufeinanderfolgenden
Adressbereichen (also solchen, die durch Zusammenfassen zu einem
kürzeren
Adress-Prefix aggregiert werden könnten) und der geographischen
Lage des Zielnetzes (die wiederum letztendlich das Routing bestimmt)
gibt. Außerdem
ist der Verschnitt zwischen Adressen und Routing noch dadurch verstärkt, dass diese
Netze in der Regel an unterschiedliche Kernnetzbetreiber angeschlossen
sind.
-
Die
Möglichkeit
der Aggregation von Verkehrsflüssen,
die von einem Policer gemeinsam behandelt werden sollen, beschränkt sich
daher heute auf die Angabe eines Zielnetz-Präfix. Da es derzeit über 100000
aktive Zielnet-Adressen im Internet gibt, ergibt sich nur ein relativ
geringer Aggregationsgewinn bei einer derartigen Zusammenfassung,
so dass weiterhin eine hohe Rate von Konfigurationsänderungen
in den Routern nötig
ist und auch eine sehr große
Anzahl von Policern gebraucht wird.
-
Bisher
wird Policing in IP-Netzen nur am Netzeingang eingesetzt, um die
gesamte Bitrate zu kontrollieren, die ein Teilnehmer ins Netz hereinschicken
kann. Diese Policer werden überdies
relativ statisch konfiguriert, d.h. entweder dauerhaft auf Basis eines
Nutzungsvertrages oder per Zugangssitzung des Teilnehmers. Es können keine
zuverlässigen QoS-Zusagen gemacht werden.
-
Der
Erfindung liegt das Problem zugrunde, ein Verfahren zum Policen
von durch eine Sammel-Reservierung erfassten Paketverkehr anzugeben,
bei dem die Konfiguration des Policers nicht immer wieder für eine Einzel-Reservierung
geändert werden
muss.
-
Das
Problem durch die Merkmale des Anspruchs 1 gelöst.
-
Bei
dem erfindungsgemäßen Verfahren
bestimmt also der Netzausgang welcher Policer einzusetzen ist. Die
vorgeschlagene Konfigurationsmöglichkeit
der Aggregatbeschreibung vereinfacht die Konfiguration des Policings
deutlich und erlaubt es insbesondere, einige wenige Aggregate zu
definieren, die von ihrer Beschreibung her zeitlich stabil sind.
Die Konfiguration des Policers muss nicht immer wieder für eine Einzel-Reservierung geändert werden.
Die erforderliche Anzahl vorzuhaltender Ratenbegrenzungseinrichtungen
wird erheblich reduziert.
-
Vorteilhafte
Weiterbildungen des Anmeldungsgegenstandes sind in den Unteransprüchen angegeben.
-
Der
Anmeldungsgegenstand wird im folgenden als Ausführungsbeispiel in einem zum
Verständnis
erforderlichen Umfang anhand von Figuren näher erläutert. Dabei zeigen:
-
1 einen
Ausschnitt aus der Adresszuordung der IP-Adressen 129.* (siehe http://www.ipindex.net/),
-
2 ein
Beispielnetz mit Routern RA, RB und RC mit angeschlossenen Netzen
N1–N9,
wobei die dargestellte Konnektivität dem Routing zu diesen Netzen
entsprechen soll,
-
3 die
Konfiguration von Aggregatbeschreibungen in herkömmlichen Routern, symbolisch dargestellt
für die
nötige
Konfiguration an einem Interface von Router RA,
-
4 die
Konfiguration von Aggregatbeschreibungen in erfindungsgemäßen Routern,
symbolisch dargestellt für
die nötige
Konfiguration an einem Interface von Router RA und
-
5 die
Realisierung der Erfindung in einer externen, dem IP-Router vorschaltbaren
Einheit.
-
In
den Figuren bezeichnen gleiche Bezeichnungen gleiche Elemente.
-
Ein
IP-Router muss neben der direkten Angabe von Quell- und Zieladressen
für die
Paket-Klassifikation auch die Angabe des Egress-Knotens des betrachteten
Netzes (z.B. OSPF oder IS-IS Routing domain) erlauben. Damit kann
der in einem Netzbereich maximal mögliche Aggregationsgewinn,
nämlich
die Zusammenfassung aller Pakete zwischen einem Eingang und einem
Ausgang des Netzes zu einem Aggregat, ausgeschöpft werden. Durch entsprechende
Verknüpfungen
mit weiteren Adress-Informationen können auch kleinere Aggregate
realisiert werden.
-
In
dem Beispielszenario aus 2 erreichen die beiden Netze
N1 und N2 über
den Router RA die weiteren Netze N3 bis N9. Dazu werden Pakete zu N4,
N6, N7 und N8 über
RB sowie zu N3, N5 und N9 über
RC aus dem Netz geleitet. Da der Ressourcenverbrauch im betrachteten
Netz N0 durch den Weg vom Ein- zum Ausgang in diesem Netz bestimmt wird,
bietet es sich an, zwei Aggregate zu definieren, eines von RA nach
RB und eines von RA nach RC. Die entsprechenden Regeln für die Zuordnung
der Pakete zu Policern in heutigen Routern sind in 3 skizziert,
während
die Regeln nach der erfindungsgemäßen Lösung in 4 dargestellt
sind.
-
Die
vorgeschlagene Konfigurationsmöglichkeit
der Aggregatbeschreibung vereinfacht die Konfiguration des Policings
deutlich und erlaubt es insbesondere, einige wenige Aggregate zu
definieren, die von ihrer Beschreibung her zeitlich stabil sind.
So kommt man in einem Netz mit N Randknoten pro Eingangs-Interface
mit der Konfiguration von N-1 Aggregatbeschreibungen pro Verkehrsklasse
aus. Wenn sich die reservierte Bandbreite des Aggregats ändert, muss
nicht mehr die Aggregatbeschreibung, sondern nur noch die Policer-Konfiguration geändert werden. Wie
oft dies geschehen soll, kann der Netzbetreiber abwägen in seinem
Entscheidungsspielraum zwischen hoher Ressourcenauslastung bei häufigen Konfigurationsänderungen
einerseits und selteneren Konfigurationsänderungen bei geringerer Ressourcenauslastung
andererseits.
-
Ansatz zur Realisierung
im Router
-
In
heutigen Routern findet die Paketweiterleitung auf der Basis einer
forwarding table statt, die auf die einzelnen Interface-Karten geladen
wird, nachdem sie im zentralen Rou ting-Prozessor zusammengestellt
wurde. Im Routing-Prozessor wird aufgrund der Informationen von
BGP (border gateway protocol, das Routing-Protokoll für inter-domain
routing) oder statischer Einträge
zunächst
für jedes
Zielnetz der Ausgangsknoten aus dem Netz bestimmt. Anschließend wird
auf der Basis der Informationen des Routing-Protokolls innerhalb
der Netzdomäne
(z.B. OSPF oder IS-IS) der jeweils nächste Knoten (next hop) auf
dem Weg zu diesem Ausgangsknoten bestimmt. Danach wird die Routing-Tabelle
zusammengestellt, die direkt für
jedes Zielnetz einen Eintrag mit dem entsprechenden next hop enthält (bei ECMP/equal
cost multi-path Routing können
es auch mehrere next hops sein). Diese Routing-Tabelle wird dann
als forwarding table in die Interface-Karten geladen.
-
Eine
erste Möglichkeit
zur Realisierung der Erfindung besteht darin, dass die forwarding
table um einen Eintrag „egress
router" erweitert
wird, so dass bei der Weiterleitung eines Paketes in Echtzeit die
Information zur Verfügung
steht, an welchem Knoten ein Paket das Netz verlassen wird.
-
Eine
weitere Möglichkeit
zur Realisierung der Erfindung besteht darin, dass die forwarding
table selbst in zwei Teile zerlegt wird, so dass bei jeder Paketweiterleitung
zunächst
in einem ersten Schritt der Ausgangsknoten aus der BGP-Tabelle ausgelesen wird
und anschließend
der next hop auf dem Weg zu diesem Ausgangsknoten aus der OSPF (oder IS-IS)-Tabelle ausgelesen
wird. Da die Schritte getrennt nacheinander ablaufen können, würde sich
für eine
Pipelining-Architektur
nur eine größere Durchlaufzeit
der Pakete, aber keine höhere
Komplexität der
Tabellen-Lookups ergeben. Zusätzlich
hätte diese
Variante den Vorteil, dass bei Änderungen
im BGP- oder OSPF (oder IS-IS)-Routing jeweils nur eine der Tabellen
im Routing-Prozessor neu berechnet und an die Interface-Karten verteilt
werden müsste.
Insbesondere die Reaktion auf netz-interne Fehler (z.B. Linkausfälle) ließe sich
dadurch nochmals deutlich beschleunigen, weil die OSPF (oder IS-IS)-Routingtabelle
in der Regel wesentlich kleiner ist als die von BGP importierte.
-
Ausführung als
externe Einheit
-
Alternativ
zur Integration in IP-Routern kann die oben beschriebene Funktion
auch zusammen mit dem Policing und einer eventuellen Paketmarkierung in
eine externe Einheit ausgelagert werden. Dies ist in 5 schematisch
dargestellt. Die externe Policing-Einheit muss am BGP-Routing und
eventuell auch am Routing des betrachteten Netzes mithören, um
die Zuordnung zwischen Zielnetzen und Ausgangsroutern des Netzes
durchzuführen.
Aus den Routing-Informationen wird eine Tabelle erzeugt, in der
mittels derselben Verfahren, die auch in IP-Routern eingesetzt werden,
zu einer gegebenen Zieladresse eines Paketes der Ausgangsrouter
gefunden wird. Die Policing-Einheit
wird den externen Interfaces des IP-Routers vorgeschaltet und anstelle des
Routers durch die Admission Control-Einheit konfiguriert.