Aggregation der inter-domain Ressourcen-Signalisierung

Die Erfindung betrifft ein Verfahren und eine Vorrichtung zur effizienten Anpassung von Ressourcenreservierungen bei Routenänderungen im Rahmen von inter-domain Routing.

An das Routing zwischen verschiedenen Netzen, inter-domain Routing, und die dazu erforderliche Signalisierung werden vor allem dort hohe Anforderungen gestellt, wo eine Vielzahl von Netzen im Rahmen eines Netzverbundes bei einer Ende-zu-Ende Übertragung zusammenwirken und gleichzeitig Qualitätskriterien für die Übertragung garantiert werden sollen. Das wich- tigste Beispiel für ein derartiges Szenario ist die Übertragung von Echtzeitverkehr über das auf dem IP-Protokoll basierende Internet.

Zukünftig werden IP-Netze auch Anwendungen unterstützen, die die Übertragung von Sprach-, Video- und Datenströmen beinhaltet, für welche ein schneller und zuverlässiger Transport von IP-Paketen benötigt wird. Derzeitige Entwicklungstätigkeiten zielen dahin, dass zukünftige IP- Netze neben dem traditionellen "best effort" Dienst neue Übertragungsdienste bereitstellen, die dem Verkehr die benötigten Bandbreiten durchgängig verfügbar machen und IP- Pakete mit geringen, kaum schwankenden Verzögerung und sehr geringen Paketverlustraten zuverlässig zum Empfänger übertragen. Ein Netz, welches für die Realisierung dieser neuen Übertragungsdienste ausgestattet ist, wird auch als NGN (Next Gerneration Network) bezeichnet. Verkehr, welcher im Rahmen dieser Dienste transportiert wird, wird auch als QoS- Verkehr (QoS: Quality of Service) bezeichnet.

Das heutige Internet ist ein Zusammenschluss einer wachsenden Anzahl einzelner IP-Netze, so genannter autonomer Systeme (AS) oder Routingdomänen, die von unterschiedlichen Organisationen verwaltet und gesteuert werden. Zur Zeit besteht das Internet aus mehr als 15000 autonomen Systemen. Ähnlich werden zukünftig NGNs zu einem Netzverbund zusammengeschlossen und QoS-Dienste netzübergreifend angeboten.

Um QoS-Dienste anbieten zu können, müssen die dafür benötigten Ressourcen nicht nur innerhalb eines NGNs sondern auch auf den Verbindungen zwischen den NGNs reserviert werden. Derzeit existieren dafür zwei Vorschläge für ein inter-domain Resourcen Signalisierungsprotokoll, das Border Gateway Reservation Protocol (BGRP, Pan, P., E. Hahne, H. Schulzrinne: "BGRP: Sink-Tree-Based Aggregation for InterDomain Reservations", Journal of Communications and Networks, Vol. 2, No. 2, pp. 157-167, http://www.cs.columbia.edu/~pingpan/papers/bgrp.pdf, June

2000) und das Shared-segment Inter-domain Control Aggregation Protocol (SICAP, R.Sofia, R.Guerin and P.Veiga: "SICAP, a Shared-segment Inter-domain Control Aggregation Protocol", High Performance Switching and Routing, HPSR 2003, Turin, Italy, June 2003) . Beide Protokolle unterscheiden sich hauptsächlich in ihrem Aggregationsverhalten.

Unter Aggregation versteht man in diesem Zusammenhang das Zusammenfassen von Reservierungen für verschiedene QoS- Verkehrsströme, dass heißt von einzelnen Verbindungen oder von kleineren Aggregaten, zu einer gemeinsamen Reservierung. Die mit der Aggregation von Reservierungen zusammengefassten Verkehrsströme bilden dann ein Aggregat zu dem im Weiteren

nur noch eine einzelne Reservierung verwaltetet werden muss. Bei BGRP werden alle Reservierungen zu einem Ziel zusammengefaßt. SICAP aggregiert zusätzlich noch auf Zwischenabschnitten der Ende-zu-Ende Pfade.

Die Aggregierung von inter-domain Reservierungen ist notwendig, um die Anzahl der notwendigen Reservierungen für QoS- Verkehr zwischen der sehr großen Anzahl von verschiedenen autonomen Systemen so zu beschränken, dass sie mit vernünftigem Rechen- und Speicheraufwand in geeigneter Zeit übertragen und verarbeitet werden können. Ändert sich die Route zu einem Ziel, dann müssen die Aggregate des QoS-Verkehrs, der über die geänderte Route transportiert wird, aufgelöst werden, da durch die Routenänderung Aggregate ihre Gültigkeit verlieren können. Nach Routenänderungen können die Verkehrsströme, die vorher ein Aggregat gebildet haben, über verschiedene Routen laufen und damit neue Aggregate erfordern. Gründe für eine Routenänderung kann der Ausfall einer Verbindungen oder Überlast auf der benutzten Verbindung sein. Um die Aggregate auf- zulösen werden an alle beteiligten Quellen Nachrichten verschickt und die Betreffenden müssen ihre Reservierungen an die neuen Routen anpassen.

Die Erfindung hat zur Aufgabe, ein bezüglich der Signalisie- rungslast aufwandarmes und effizientes Verfahren für die Anpassung von Ressourcen-Reservierungen bei Routen-Änderungen im Rahmen von inter-domain Routing anzugeben.

Erfindungsgemäß wird vorgeschlagen, bei einer Routen- Auflösung und dadurch bedingten Umlegen bzw. Umleiten von Verkehr Ressourcen-Reservierungen zusammenzufassen, um die Signalisierung möglichst effizient zu gestalten.

Im Zuge der Erfindung wird bei einer Routen-Änderung im Rahmen von inter-domain Routing einer ersten Routingdomäne eine Änderung einer inter-domain Route mitgeteilt (dabei kann es sich sowohl um eine Zurückziehung einer inter-domain Route oder die Mitteilung einer geänderten inter-domain Route handeln) , welche eine Anpassung von Ressourcen-Reservierungen erfordert. Die erste Routingdomäne teilt dann diese Änderung, z.B. in Form einer Routen-Änderungsnachricht (z.B. UPDATE- Nachricht des BGP-Protokolls) zumindest einer zweiten und ei- ner dritten Routingdomäne, vorzugsweise aber allen benachbarten Routingdomänen, von denen aus QoS-Verkehr über die erste Routingdomäne entlang der von der Änderung betroffenen Route transportiert wurde, mit. Von der zweiten und der dritten Routingdomäne werden jeweils der ersten Routingdomäne eine nach Maßgabe der Routen-Änderung angepasste Ressourcen- Reservierung signalisiert, die z.B. Ressourcen entlang einer alternativen Route oder neuen Route anfordert. Diese signalisierten bzw. mitgeteilten Ressourcen-Reservierungen werden von der ersten Routingdomäne zusammengefasst und weiterkommu- niziert, normalerweise an eine vierte Routingdomäne, von der ursprünglich die Routen-Änderung an die erste Routingdomäne kommuniziert wurde.

Die Erfindung hat den Vorteil, dass Ressourcen-Reservierungen zusammengefasst weiterkommuniziert werden und so der Signali- sierungsaufwand optimiert wird. Die Anzahl der Signalisie- rungsnachrichten beim Auflösen und Neuerstellen eines Aggregates werden so deutlich verringert.

Das erfindungsgemäße Vorgehen kann zu einer Verzögerung von

Ressourcen-Reservierungen führen, wenn z.B. die von der zweiten Routingdomäne signalisierte Ressourcen-Reservierung erst mit Verzögerung eintrifft, wodurch auch die Zusammenfassung der Ressourcen-Reservierungen von den Routingdomänen zwei und drei erst verzögert weitergegeben wird. In diesem Fall erfolgt auch die Ressourcen-Reservierung der dritten Routingdomäne mit einer Verzögerung, die ohne Aggregation bzw. Zusam-

menfassung der Reservierungen nicht gegeben wäre. Wegen dieser Schwierigkeit wird gemäß einer Weiterbildung vorgeschlagen einen Timer oder Zeitgeber einzuführen und nur innerhalb der Laufdauer des Timers empfangene Ressourcen-Reservierungen zusammenzufassen. Falls alle Ressourcen-Reservierungen innerhalb der Laufzeit des Timers empfangen werden, können diese zusammen (evtl. noch vor Ablauf des Timers) weitergegeben werden. Anderenfalls werden nur die während der Laufdauer des Timers erhaltenen Ressourcen-Reservierungen in aggregierter Form weitergegeben. Später eintreffende Ressourcen- Reservierungen können dann als Einzelreservierungen nicht ag- gregiert bzw. nicht zusammengefasst weiter kommuniziert werden.

Es ist sinnvoll, von der ersten Routingdomäne entlang bestehender Inter-Domain-Routen die Routing-Änderung den Routingdomänen mitzuteilen, die Ressourcen entlang Routen reserviert haben, die über die erste Routingdomäne zu einem gemeinsamen Ziel führen und von der Routen-Änderung betroffen sind. Es ergibt sich damit ein Routen-Baum von Routen, die von der ersten Routingdomäne die Routen-Änderung kommuniziert bekommen. Gemäß einer Ausführungsform des Anmeldungsgegenstandes wird bei der Rückrichtung beim Durchlaufen des Baumes mit geänderten Ressourcen-Reservierungen bei den Routingdomänen, die keinen „Blatt-Knoten" darstellen, d. h. kein Endpunkt sind, eine erfindungsgemäße Aggregation der Ressourcen- Reservierungen durchgeführt. Das gemeinsame Ziel bzw. die Wurzel eines Routen-Baumes oder einer Mehrzahl von Routen, wodurch festgelegt ist, welche Routen-Reservierungen zusam- mengefasst werden können, ist beispielsweise durch eine Routingdomäne gegeben, die den Endpunkt der Routen darstellt. Es ist aber auch vorstellbar, dass es sich nicht um eine Routingdomäne, sondern um ein Netz - z. B. definiert durch eine bestimmte Adresse - handelt, welches einen Teil einer Domäne bilden kann. Ebenso ist das Ziel nicht notwendigerweise der Endpunkt von Routen, sondern kann einen geeignet gewählten Zwischenpunkt bzw. eine geeignet gewählte, entlang einer Rou-

te, liegende Domäne sein. Eine nicht nur auf die Endpunkte bezogene Aggregation von Reservierungen ist beispielsweise auch in einem zu dieser Anmeldung verschiedenen Kontext im SICAP-Protokoll vorgesehen.

Die obige Ausgestaltung des Erfindungsgegenstandes kann vorteilhaft dadurch erweitert werden, nicht nur in der ersten Routingdomäne, sondern auch in anderen Routingdomänen, denen die Routen-Änderung über die erste Routingdomäne mitgeteilt wird und welche nicht den Endpunkt einer Route bilden, ebenfalls einen Timer zur Aggregation von Ressourcen- Reservierungen zu starten. So kann beispielsweise in der zweiten Routingdomäne ebenfalls ein Timer gestartet werden; vorzugsweise werden jedoch in allen Routingdomänen Timer ge- startet, die ausgehend von der ersten Domäne über die Routing-Änderung informiert werden und welche daraufhin Ressourcen-Neureservierungen von mehr als einer Domäne zu demselben Ziel empfangen.

Bei einer Verwendung mehreren Timern ist es von Vorteil, die Timer aufeinander abzustimmen. Durch eine derartige Abstimmung soll erreicht werden, dass falls eine Routingdomäne, welche nach Ablauf ihres Timers die bis dahin eingegangenen Ressourcen-Reservierungen zu einer Reservierung zusammenfasst und diese einer bezüglich der geänderten Route nachfolgenden Routingdomäne signalisiert, der Timer dieser Routingdomäne ebenfalls noch nicht abgelaufen ist, so dass die signalisierte (aggregierte) Routen-Reservierung mit weiteren Routen- Reservierungen aggregiert bzw. zusammengefasst werden kann. Deshalb ist es angebracht, die Laufdauer eines Timers einer

Routingdomäne kürzer als die Laufzeit des Timers der Routingdomäne zu wählen, an die dann die aggregierten Routen- Reservierungen signalisiert werden.

In einer bevorzugten Ausführungsform findet eine derartige Abstimmung der Laufdauer der Timer für alle Routingdomänen statt, die Routen-Reservierungen aggregieren und dafür mit

Timern arbeiten. Man kommt so zu einer Art Timer-Kaskade oder Timer-Interwall-Schachtelung, wo die Laufdauer der Timer umso kürzer wird, je weiter man sich im Routen-Baum den Endpunkten bzw. Blatt-Knoten nähert. Im Allgemeinen ist dann die Lauf- zeit eines Timers umso kürzer, je später er gestartet wird. Eine Abstimmung der Timer aufeinander kann durch Austausch von einer Information geschehen, die beispielsweise Bestandteil der Routen-Änderungsnachricht ist. Diese Information kann beispielsweise die Laufdauer des Timers beinhalten, die zusammen mit der Übertragungsdauer der Nachricht, welche häufig vom Protokoll aus, z.B. in Form eines Zeitstempels (Time- Stamp) schon vorgesehen ist, verwendet werden, um eine geeignete Laufdauer für den Timer zu ermitteln. Andere Lösungen sind ebenfalls denkbar, beispielsweise kann man sich auch vorstellen, dass Erfahrungswerte für eine passende Laufdauern von Timern nach Maßgabe des Abstandes der Routingdomäne von der im Baum am Weitesten vorne gelegenen Domäne gegeben ist. Bei dieser Ausgestaltung muss beispielsweise eine Domäne, welche bezüglich der Timer verwendenden Routingdomänen an dritter Stelle gelegen ist, einer nachfolgenden Routingdomäne nur die Information weiterleiten, dass diese an vierter Stelle gelegen ist, so dass diese die für diese Position vorgesehene Laufdauer wählt.

Die Erfindung beinhaltet auch eine Vorrichtung, z. B. einen Router, mit Mitteln zur Durchführung eines erfindungsgemäßen Verfahrens .

Im Folgenden wird der Erfindungsgegenstand im Rahmen eines Ausführungsbeispiels anhand von Figuren näher erläutert.

Es zeigen

Figur 1 Routingdomänen mit Ressourcen-Reservierungs- Aggregierung für Routing zu einem Zielnetz Nl.

Figur 2 die in Figur 1 gezeigten Routingdomänen mit einer erfindungsgemäßen Aggregierung von neuen Routen- Reservierungen bei einer Änderung von zu dem Ziel Nl führenden Routen.

Anhand von Fig. 1 wird dargestellt, welche Nachteile das Vorgehen gemäß des Standes der Technik hat. Der grundsätzliche Ablauf bei der Aggregation und Deaggregation von BGRP und SICAP ist sehr ähnlich und hat damit dasselbe Problem, das in dieser Anmeldung gelöst wird. Deswegen wird im Folgenden nur noch BGRP betrachtet.

Fig. 1 zeigt ein Beispiel von Aggregation von Reservierungen entsprechend BRGP. In dem gezeigten Netzverbund hat jedes der vier autonomen Systeme AS4, AS5, AS6 und AS7 je eine Reservierung zum Zielnetz Nl aufgebaut. Die Reservierungen beginnen mit den Reservierungen Fl, F2, F3 und F4 zwischen einem der autonomen Systeme AS4, AS5, AS6 und AS7 und AS2 bzw. AS3 und werden schrittweise zu größeren Aggregaten zusammenge- fasst. Das autonome System AS2 hat die beiden Reservierungen Fl und F2 von dem autonomen System AS4 bzw. dem autonomen System AS5 zu dem Aggregat Al in Richtung ASl zusammenge- fasst. Analog hat das autonome System AS3 die beiden Reservierungen F3 und F4 von dem autonomen System AS6 bzw. dem au- tonomen System AS7 zum Aggregat A2 zusammengefasst. Das autonome System ASl hat die beiden Aggregate Al und A2 nochmals zu einem größeren Aggregat A12 zusammengefasst. Ausgehend von den Reservierungen Fl, F2, F3 und F4 entsteht so ein baumartiges System von Reservierungen, das im Folgenden Reservie- rungsbaum genannt wird. Jedes der autonomen Systeme AS4, AS5, AS6 und AS7 verwendet seine Reservierung Fl, F2, F3 bzw. F4 für den gesamten QoS-Verkehr mit Zieladressen mit dem Prefix 10.10.10.0/23.

In diesem Beispiel wird angenommen, daß auf der direkten Verbindung zwischen ASl und dem Zielnetz Nl die Last des QoS- Verkehrs eine vom Netzwerk Management festgelegte Grenze ü- berschreitet und deshalb ein Teil des Aggregates A12 über AS8 zum Zielnetz geroutet werden soll. Dazu werden der Prefix 10.10.10.0/23 in die beiden Prefixe 10.10.10.0/24 und 10.10.11.0/24 aufgespaltet, wie in Fig. 2 gezeigt, und über das Routingprotokoll an alle betroffenen autonomen Systeme entsprechende Routingnachrichten weitergeleitet. Daraufhin müssen alle autonomen Systeme (AS1-7), deren QoS-Verkehr Bestandteil des Aggregates A12 ist, ihre Reservierungen zum Prefix 10.10.11.0/23 an den neuen Pfad über AS8 anpassen. Ü- ber das Routingprotokoll wird zumindest eine neue Route mit dem Prefix 10.10.11.0/24 bekannt gegeben, die von dem autono- men System ASl über das autonome System AS8 zu dem Netz Nl führt. Damit soll der Verkehr zu diesem Prefix von der zu hoch belasteten direkten Verbindung zwischen dem autonomen System ASl und dem Zielnetz Nl auf den Pfad von dem autonomen System ASl über das autonome System AS8 zu dem Zielnetz Nl umgelegt werden. Auf die neue Route reagiert das Ressoucenma- nagement des autonomen Systems ASl und schickt eine Nachricht an die autonomen Systeme AS2 und AS3 mit der Aufforderung, dass diese ihre bestehenden Reservierungen neu aufbauen. Die autonomen Systeme AS2 und AS3 senden in Folge eine entspre- chende Nachricht an ihre Nachbarn, die autonomen Systeme AS4, AS5, AS6 und AS7. Diese Nachrichten laufen also in umgekehrter Richtung zu den bestehenden Reservierungen auf dem Reservierungsbaum von der Wurzel zu den Blättern, d.h. zu den Knoten, an dem die einzelnen Reservierungen beginnen, zurück. Von dort aus werden jetzt neue Reservierungen aufgebaut. Aufgrund des geänderten Routings unterteilt das autonome Systeme AS4 seine Reservierung Fl in zwei Reservierungen Fla und FIb entsprechend dem Verkehr zu den beiden Prefixen 10.10.10.0/24

und 10.10.11.0/24, die nun über unterschiedliche Routen erreicht werden. Die autonomen Systeme AS5, AS6 und AS7 reagieren analog und es entstehen zwei neue Reservierungsbäume.

Das Zurücksignalisieren auf dem Reservierungsbaum und das erneute Aufbauen aller Reservierungen wird im realen Internet, wo wesentlich größere Reservierungsbäume entstehen, eine sehr große Anzahl von Signalisierungsnachrichten erzeugen.

Im Folgenden wird das erfindungsgemäße Vorgehen dargestellt. Nach Aufspalten des Prefix 10.10.10.0/23 in die beiden Prefi- xe 10.10.10.0/24 und 10.10.11.0/24 werden über das Routingprotokoll an alle betroffenen autonomen Systeme entsprechende Routingnachrichten weitergeleitet. Daraufhin müssen alle autonomen Systeme (AS1-7), deren QoS-Verkehr Bestandteil des Aggregates A12 ist, ihre Reservierungen zum Prefix 10.10.11.0/23 an den neuen Pfad über das autonome System AS8 anpassen. Das autonome System ASl bemerkt das veränderte Routing an einem Zeitpunkt Tl . Daraufhin sendet das autonome System ASl an alle Nachbarn, aus deren Reservierungen das Aggregate A12 zum Zeitpunkt Tl aufgebaut ist, d.h. an die autonomen Systeme AS2 und AS3, eine Nachricht, die diese veran- lasst, die Reservierungen gemäß den geänderten Routing zu ü- berprüfen und mit neuen Reservierungen an das autonome System ASl zu antworten. Gemäß der Erfindung wartet das autonome

System ASl dann auf Antworten der benachrichtigten autonomen Systeme AS2 und AS3 und überwacht mit einem Timer die maximale Antwortzeit. Das autonome System ASl wartet auf vier Reservierungen, je eine für die beiden Prefixe 10.10.10.0/24 und 10.10.11.0/24 von dem autonomen System AS2 und von dem autonomen System AS3. Sei T2 der Zeitpunkt, an dem entweder alle erwarteten Antworten eingetroffen sind oder der Timer abgelaufen ist (das frühere der beiden Ereignisse) . In der

Zwischenzeit: ΔTl = T2 - Tl, baut das autonome System ASl entsprechend der eintreffenden Reservierungen zwei neue Aggregate auf: je ein Aggregat für die direkte Verbindung zu Nl (Prefix 10.10.10.0/24) und für den Pfad über das autonome System AS8 (Prefix 10.10.11.0/24) . Gemäß der Erfindung werden während ΔTl einlaufende Signalisierungsnachrichten, die Reservierungen des aufgelösten Aggregates A12 zum Zeitpunkt Tl betreffen, nicht weiter in Richtung Ziel signalisiert. Lediglich neue Reservierungen, die nicht Bestandteil des aufgelös- ten Aggregates A12 zum Zeitpunkt Tl sind werden wie gewohnt behandelt. Die Zuordnung von einlaufenden Reservierungen zum aufgelösten Aggregat A12 geschieht über einen eindeutigen I- dentifier der von dem autonomen System ASl mit der Auflösungsnachricht an die autonomen Systeme AS2 und AS3 versandt wurde und in den zurücklaufenden Antworten enthalten ist. Erst zum Zeitpunkt T2 signalisiert das autonome System ASl die beiden neuen Aggregate in Richtung Zielnetz Nl.

Die autonomen Systeme AS2 und AS3 reagieren erfindungsgemäß wie das autonome System ASl auf dessen Nachricht, die Reservierungen des Aggregates A12 neu aufzubauen. Erst wenn das autonome System AS2 je eine neue Reservierungen für die beiden Prefixe 10.10.10.0/24 und 10.10.11.0/24 von AS4 und von AS5 erhalten hat, oder ein entsprechender Timer abgelaufen ist, sendet das autonome System AS2 zwei Reservierungsnachrichten an das autonome System ASl, je eine für jeder der beiden Prefixe. Das autonome System AS3 reagiert analog. Sollen für einen Prefix keine Ressourcen reserviert werden, dann kann eine Reservierung mit dem Betrag 0 erfolgen, um nicht den Ablauf des Timers abwarten zu müssen.

Ausgehend von der ersten Signalisierungsnachricht, mit der das autonome System ASl zum Zeitpunkt Tl den Neuaufbau der

Reservierungen des Aggregats A12 veranlasst, werden mit dem neuen Verfahren insgesamt 6 + 12 Signalisierungsnachrichten benötigt (6 zum Auflösen der Aggregate zwischen AS4, AS5, AS6, AS7 und ASl + 12 zum Neuaufbau) . Ohne das neue Verfahren werden 6 + 24 Signalisierungsnachrichten benötigt. Insbesondere die Belastung des autonomen Systems ASl sinkt mit dem neuen Verfahren von 8 Antworten auf 4, halbiert sich also schon in diesem kleinen Beispiel.

Es ist sinnvoll, die Laufdauer der Timer aneinander anzupassen. So startet das autonome System ASl einen Timer und sendet eine Nachricht an die autonomen Systeme AS2 und AS3. Autonome System AS2 startet dann wieder einen Timer und sendet eine Nachricht an die autonomen Systeme AS4 und AS5. Angenom- men, das autonome System AS4 antwortet nicht rechtzeitig, dann läuft der Timer des autonomen Systems AS2 ab. Das autonome System AS2 sendet die Reservierungen AIa und Alb an das autonome System ASl. Wenn die Timer von der autonomen Systeme AS2 und AS3 dieselbe Zeitspanne umfassen, dann ist der Timer von dem autonomen System ASl bereits abgelaufen, die Reservierungen von dem autonomen System AS2 werden bei der Aggregation also nicht mehr berücksichtigt. Dies kann verhindert werden, wenn die Zeitspannen der Timer aufeinander abgestellt bzw. angepasst werden (je weiter im Baum, desto kürzer) . Dies kann z.B. durch Einfügen der Zeitspanne des Timers in die Nachrichten zwischen den autonomen Systemen realisiert werden. Z.B. teilt das autonome System ASl dem autonomen System AS2 die Laufdauer seines Timers mit, das autonome System AS2 wählt dann eine kürzere Laufdauer, die es er- laubt, die Reservierungsnachrichten vor Ablauf des Timers des autonomen Systems ASl zu senden. Diese kürzere Laufdauer des Timers berücksichtigt die Laufdauer der Nachrichten, die zwischen dem autonomen System ASl und AS2 ausgetauscht werden.

Die Laufdauer ist dann zumindest um das Zweifache der Laufdauer ausgetauschter Nachrichten geringer (Laufzeit der Routen-Änderungsnachricht + Laufzeit der Nachricht mit den ag- gregierten Reservierungen) .