EP1897341A1 - Verfahren zur effizienten behandlung von störungen bei der paketbasierten übertragung von verkehr - Google Patents
Verfahren zur effizienten behandlung von störungen bei der paketbasierten übertragung von verkehrInfo
- Publication number
- EP1897341A1 EP1897341A1 EP06763437A EP06763437A EP1897341A1 EP 1897341 A1 EP1897341 A1 EP 1897341A1 EP 06763437 A EP06763437 A EP 06763437A EP 06763437 A EP06763437 A EP 06763437A EP 1897341 A1 EP1897341 A1 EP 1897341A1
- Authority
- EP
- European Patent Office
- Prior art keywords
- routing
- change
- protocol
- path
- domain
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1441—Countermeasures against malicious traffic
- H04L63/1458—Denial of Service
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection
Definitions
- the invention relates to a method for the efficient handling of disturbances in the packet-based transmission of traffic by means of a routing protocol.
- the invention is in the field of Internet technologies or, more specifically, in the field of routing in packet-oriented networks and aims at the transmission of data under real-time conditions.
- networks In a data transmission over the Internet are usually networks - one also speaks of subnets, of domains or so-called autonomous systems (the English Autonomous System) - various network operators involved.
- the network operators are responsible for routing within the domains that fall within their area of responsibility. Within these domains, they have the freedom to customize the routing procedure as they wish, as long as only quality of service features can be met. The situation is different in routing between different domains, where different domain operators connect with each other. Interdomain routing is complicated by the need to determine optimal paths across different domains to the destination, but allows local operators to apply local strategies that influence a global calculation of optimal paths according to objective criteria. For example, one strategy is to avoid domains of network operators of a particular country for traffic of a particular origin.
- Border Gateway Protocol For routing between different domains so-called Exterior Gateway Protocols EGP are used.
- BGP Border Gateway Protocol version 4
- RFC Request for Comments
- the Border Gateway Protocol is a so-called Path Vector protocol.
- a BGP instance (the term "BGP speaker” is often found in English-language literature) is informed by its BGP neighbors about possible routes to destinations to be reached via the respective BGP neighbor.
- the BGP instance contains the optimal route from the local point of view to the achievable goals.
- update or update message As part of the BGP protocol, four types of messages are exchanged between BGP instances, including a so-called update or update message, which propagates path information throughout the network and allows the network to be optimized according to topology changes.
- the transmission of update messages usually leads to an adaptation of the path information in all BGP instances of the network in terms of a routing optimized according to the locally available information.
- so-called keepalive or status confirmation messages play a role, with which a BGP instance informs its BGP neighbors about its functionality. In the absence of these messages, the BGP neighbors assume that the link to the BGP instance is disturbed.
- the method has the disadvantage that it involves the risk of a potential loss of connection, which is not tolerable for real-time traffic.
- EP 1453250 describes an approach to supplement the BGP protocol with a method for a rapid response to link failures in interdomain routing. This approach provides for provision of replacement paths, without requiring prior propagation of change messages throughout the network. A change of the routing is made only along substitute paths. This limited reordering of the routing allows a quick response to
- a topology adaptation in the network can additionally be carried out by means of the BGP protocol.
- the object of the invention is to make the response of packet-based networks more efficient to fault messages.
- the object is achieved by a method according to claim 1.
- the invention is based on the recognition that in many cases technologies or protocols with fault detection and fault correction mechanisms are used simultaneously, which lead to separate, independent reactions. These reactions can run on different time scales and differ greatly in the resulting network load.
- the invention aims to suppress slow and expensive troubleshooting mechanisms when a parallel mechanism results in troubleshooting or when the error is of such short duration that remedy on the time scale of the troubleshooting mechanism is not meaningful.
- the troublesome BGP protocol is sometimes used in conjunction with the OSPF protocol or the MPLS (multi protocol label switching) protocol. Both protocols have troubleshooting mechanisms with a faster response time compared to the BGP protocol.
- the invention aims at such constellations.
- a routing entity responds to a message of the unavailability of a neighboring routing entity with respect to the routing by means of a routing protocol by sending a
- neighbor routing instance to check for unreachability or loss of connectivity. Only if the test message does not receive any positive feedback regarding the availability, a change of the routing to avoid the failed connection to the neighboring routing entity is made.
- neighboring routing entity is understood to mean that it is a neighbor or "next hop” in the sense of the routing protocol. A neighborhood with respect to the physical communication infrastructure does not necessarily exist.
- a neighbor routing instance can ter domain routing also denote an adjacent autonomous system.
- the invention leads to a more efficient use of existing resources in troubleshooting.
- a troubleshooting or routing change using the routing protocol is avoided in three important cases where such a change is not required:
- the error is a short-term instability that no longer exists when sending the test message.
- Such instabilities can initiate the routing convergence process, which, in particular in the case of BGP, results in a global (in the sense of the Internet) load on the network due to update messages.
- Unreachability can be ascertained, for example, by means of the test message by specifying a time interval for a response (e.g., a mirrored test message) and if the response is absent within the time interval of the response (e.g., a mirrored test message) and if the response is absent within the time interval of the response (e.g., a mirrored test message) and if the response is absent within the time interval of the response (e.g., a mirrored test message) and if the response is absent within the time interval of the response.
- the time interval can be adapted to the conditions of the system (eg measured delay times, traffic-type-related requirements with regard to the response time to errors).
- protocol-inherent error messages could be used in the transmission of the test message.
- the TCP transport control protocol
- Such a procedure is usually less flexible.
- the invention is preferably used in inter-domain routing, where there is the problem of a relatively slow response of EGP protocols and a greater risk of manipulated messages. For example, if the error was acknowledged, it would respond through the EGP protocol (usually BGP).
- the invention is combined with the procedure described in EP 1453250. It is assumed that interrupted by the disturbance paths, which include traversing autonomous systems.
- routing domains located on the replacement path are notified.
- the notified routing domains residing on the replacement path adjust their inter-domain routing according to routing to the destination point along the substitute path until all routing domains on the replacement path their inter-domain routing according to a routing on the substitute path to the destination point. This procedure minimizes the changes made during routing.
- a more complex adaptation of the overall topology can take place if the error proves to be permanent (persistent error).
- the method can equally well be used within an autonomous system or for intra-domain routing.
- Error responses may consist of a network-wide topology change (e.g., OSPF), provision of a failed path replacement path (e.g., in the context of the MPLS concept), or a local response (e.g., as described in WO2004 / 051957).
- OSPF network-wide topology change
- provision of a failed path replacement path e.g., in the context of the MPLS concept
- a local response e.g., as described in WO2004 / 051957.
- the invention also encompasses a device, eg a router, which comprises a routing entity and for carrying out a method according to the invention for the efficient treatment of Disturbances in the packet-based transmission of traffic is configured.
- a routing entity can be given both by a router and a software implementation of routing functions on suitable hardware.
- Fig. 1 A section of a routing architecture
- Figures 2a and 2b A protocol stack with various mechanisms for troubleshooting
- FIG. 1 schematically shows the interaction of a module or a protocol entity APCS (ACPS: adjacent peer check service) with a routing protocol layer (RPE), which communicate with one another via an interface APCI (adjacent peer check interface) provided for this purpose.
- APCS adjacent peer check service
- RPE routing protocol layer
- APCI adjacent peer check interface
- Such a routing architecture has been used, for example, in the document "Improving Convergence Time of Routing Protocols" by G. Lichtwald, U. Walter and M. Zitterbart cited in the introduction to the description
- the routing protocol is eg the BGP protocol
- the BGP protocol sees periodic KEEPALIVE If the KEEPALIVE messages can not be delivered, an error message is issued
- the APCI interface would then cause the APCS protocol instance to send a test message or check message.
- Fig. 2a and 2b different layers of a network are shown.
- the lowest layer is MPLS (multiprotocol label switching).
- MPLS multiprotocol label switching
- a logical IP topology is established. This topology is not equal to the MPLS topology and "sees" fewer network components, ie part of the network components active at the MPLS level are on the IP level transparent.
- the BFD (Bidirectional Forwarding Detection) service is based on the IP layer view in this example.
- the Border Gateway protocol the two redundant paths of the IP layer are transparent.
- the BGP protocol only "sees" the direct session with its BGP neighbor.
- the failed link in Figure 2b is the link through which the BGP session was established.
- the BFD protocol reports the sub-second failure to the BGP router. Traditionally, this causes the BGP protocol to start the convergence process.
- the convergence process is not absolutely necessary because the BGP protocol before the initiation of the convergence process using the
- Check message at his BGP neighbor checks whether this is actually no longer available. Modern MPLS versions allow fast switching to replacement paths compared to the BGP error response. The check message in this case determines connectivity because the faster MPLS reaction preceded an error response. The BGP troubleshooting mechanism will not fire.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Die Erfindung betrifft ein Verfahren zur effizienten Behandlung von Störungen bei der paketbasierten Übertragung von Verkehr mittels eines Routingprotokolls und Routinginstanzen. Im Rahmen des erfindungsgemäßen Verfahrens findet eine Überprüfung einer Meldung der Nichterreichbarkeit einer Nachbar-Routinginstanz statt. Dabei wird nach Meldung der Nichterreichbarkeit einer Nachbar-Routinginstanz eine Testnachricht zur Überprüfung dieser Information gesendet. Bei Bestätigung der Nichterreichbarkeit im Zuge der Überprüfung wird auf einen Ausfall der Verbindung zu der Nachbar-Routinginstanz geschlossen und durch die Routinginstanz eine Änderung des Routings zur Vermeidung der ausgefallenen Verbindung veranlasst. Die Erfindung reduziert den im Zuge von Störungsbehebungen im Netz anfallenden Aufwand und schützt gegen falsche, zur Störung des Netzes erzeugte Fehlermeldungen.
Description
Beschreibung
Verfahren zur effizienten Behandlung von Störungen bei der paketbasierten Übertragung von Verkehr
Die Erfindung betrifft ein Verfahren zur effizienten Behandlung von Störungen bei der paketbasierten Übertragung von Verkehr mittels eines Routingprotokolls.
Die Erfindung liegt auf dem Gebiet der Internet-Technologien bzw. spezifischer auf dem Gebiet der Routing-Verfahren in paketorientierten Netzen und zielt auf die Übertragung von Daten unter Echtzeitbedingungen .
Die derzeit wohl wichtigste Entwicklung auf dem Gebiet der Netze ist die Konvergenz von Sprach- und Datennetzen. Ein wichtiges Zukunftsszenario ist, dass Daten, Sprache und Videoinformationen über ein paketorientiertes Netz übertragen werden, wobei neu entwickelte Netztechnologien die Einhaltung von Anforde- rungsmerkmalen für verschiedene Verkehrsklassen gewährleisten. Die zukünftigen Netze für verschiedene Arten von Verkehr werden paketorientiert arbeiten. Aktuelle Entwicklungstätigkeiten betreffen die Übertragung von Sprachinformationen über herkömmlich für Datenverkehr verwendete Netze, vor allem IP (Internet Protokoll) basierte Netze.
Um Sprachkommunikation über Paketnetze und insbesondere IP-basierte Netze in einer Qualität zu ermöglichen, die der Sprachübertragung über leitungsvermittelte Netze entspricht, müssen Qualitätsparameter wie z.B. die Verzögerung von Datenpaketen oder der Jitter in engen Grenzen gehalten werden. Bei Sprachübertragung ist von großer Bedeutung für die Qualität des angebotenen Dienstes, dass die Verzögerungszeiten Werte von 150 Millisekunden nicht wesentlich übersteigen. Um eine entsprechend geringe Verzögerung zu erreichen, wird an verbesserten Routern und Routing-Algorithmen gearbeitet, die eine schnellere Bearbeitung der Datenpakete ermöglichen sollen.
Beim Routing über IP-Netze wird üblicherweise zwischen Intradomain- und Interdomain-Routing unterschieden. Bei einer Datenübertragung über das Internet sind üblicherweise Netze - man spricht hier auch von Teilnetzen, von Domänen oder sogenannten Autonomen Systemen (vom Englischen Autonomous System) - verschiedener Netzbetreiber involviert. Die Netzbetreiber sind zuständig für das Routing innerhalb der Domänen, die in ihren Zuständigkeitsbereich fallen. Innerhalb dieser Domänen haben sie die Freiheit, die Vorgehensweise beim Routing nach eigenen Wünschen beliebig anzupassen, solange nur Dienstgütemerkmale eingehalten werden können. Anders stellt sich die Situation beim Routing zwischen verschiedenen Domänen dar, bei dem unterschiedliche Domänenbetreiber miteinander in Verbindung treten. Interdomain-Routing wird dadurch verkompliziert, dass einer- seits möglichst optimale Pfade über verschiedene Domänen zu dem Ziel bestimmt werden sollen, andererseits aber Domänenbetreiber lokal Strategien anwenden können, die eine globale Berechnung von optimalen Pfaden nach objektiven Kriterien beeinflussen. Beispielsweise besteht eine Strategie darin, für Verkehr einer bestimmten Herkunft Domänen von Netzbetreibern eines bestimmten Landes zu vermeiden. Diese Strategie ist nun aber in der Regel nicht allen Netzbetreibern mit Domänen, über die der Verkehr geroutet wird, bekannt, d.h. ein Netzbetreiber muss lokal eine Entscheidung bezüglich der Domäne treffen, zu der er Verkehr weiterleitet, ohne über vollständige Informationen über den optimalen Weg im Sinne einer Metrik zu verfügen. Die Strategien werden häufig auch mit dem englischen Ausdruck "Policies" bezeichnet .
Für das Routing zwischen verschiedenen Domänen werden sogenannten Exterior-Gateway-Protokolls EGP verwendet. Im Internet wird derzeit meist das in dem RFC (Request for Comments) 1771 genauer beschriebene Border-Gateway-Protokoll Version 4 (Border-Gateway-Protokoll wird häufig mit BGP abgekürzt) verwendet. Das Border-Gateway-Protokoll ist ein sogenanntes Path-Vector-Protokoll . Eine BGP-Instanz (der Ausdruck "BGP-Speaker" findet sich häufig in englischsprachigen Literatur)
wird von seinen BGP-Nachbarn über mögliche Wege zu über den jeweiligen BGP-Nachbar zu erreichenden Zielen informiert. Anhand von ebenfalls mitgeteilten Eigenschaften der Wege (im Englischen path attributes) enthält die BGP-Instanz zu den erreichbaren Zielen den aus ihrer lokalen Sicht jeweils optimalen Weg. Im Rahmen des BGP-Protokolls werden zwischen BGP-Instanzen vier Typen von Nachrichten ausgetauscht, darunter eine sogenannte Update- oder Aktualisierungsnachricht, mit der Weginformationen durch das ganze Netz propagiert werden und die erlaubt, das Netz entsprechend Topologie-Änderungen zu optimieren. Die Aussendung von Aktualisierungsnachrichten führt üblicherweise zu einer Anpassung der Pfadinformationen bei allen BGP-Instanzen des Netzes im Sinne eines entsprechend der lokal vorliegenden Informationen optimierten Routings . Daneben spielen sogenannte Keepalive- oder Zustandsbestätigungsnachrichten eine Rolle, mit denen eine BGP-Instanz seinen BGP-Nachbarn über seine Funktionsfähigkeit aufklärt. Bei Ausbleiben dieser Nachrichten gehen die BGP-Nachbarn davon aus, dass der Link zu der BGP-Instanz gestört ist.
Die Propagation von Topologie-Informationen mit Hilfe des BGP-Protokolls hat den Nachteil, dass bei häufigen Änderungsanzeigen eine beträchtliche Last der durch das Netz propagierten Nachrichten zur Anzeige der Änderung auftreten, und dass das Netz nicht auskonvergiert, wenn Änderungsnachrichten zu schnell aufeinander folgen. Dieses Problem, dass das Netz nicht auskonvergiert bzw. dass das Interdomain-Routing nicht stabil wird, wurde durch den sogenannten Route-flap-damping-Ansatz angegangen. Die Idee hinsichtlich dieses Konzepts ist, die Anzeige einer Änderung durch einen BGP-Nachbarn mit einer
Sanktion zu belegen. Bei Empfang einer Änderungsnachricht wird der Dämpfungsparameter erhöht und bei Überschreiten einer Schwelle durch den Dämpfungsparameter werden Änderungsmeldungen ignoriert. Der Dämpfungsparameter fällt exponentiell mit der Zeit ab. Als Folge davon werden Änderungsmeldungen von
BGP-Instanzen ignoriert, solange der Dämpfungswert nicht die untere Schwelle (Wiederbenutzungsschwelle) unterschritten hat.
Das Verfahren hat jedoch den Nachteil, dass es die Gefahr eines potentiellen Verbindungsverlustes mit sich bringt, was für Echtzeitverkehr nicht tolerierbar ist.
Im Hinblick auf die Übertragung von Echtzeitverkehr streben aktuelle Weiterentwicklungen von Interdomain-Routing ein schnelleres Erkennen und Beheben von Störungen an.
In dem RFC Draft "Bidirectional Forwarding Detection" von D. Katz und D. Ward und in der Publikation „Improving Convergence Time of Routing Protocols" von G. Lichtwald, U. Walter und M. Zitterbart (3rd International Conference on Network, 29.02.-04.03., Guadelope, ISBN 0-86341-326-9) werden Protokolle für eine beschleunigte Erkennung von Störungen beschrieben. Beide Ansätze schlagen ein von dem Routingprotokoll getrenntes Protokoll zur Überwachung der Konnektivität und zum Erkennen von Störungen vor. Diese Vorgehensweise erlaubt, die zeitliche Granularität der Überwachung den Netzbedingungen (Belastung durch Überwachungspakete) und den im Netz durchgeführten Ü- bertragungsdiensten (Echtzeitfähigkeit erforderlich oder nicht) anzupassen.
In der EP 1453250 ist ein Ansatz beschrieben, das BGP Protokoll durch ein Verfahren für eine schnelle Reaktion auf Linkausfälle beim Interdomain-Routing zu ergänzen. Dieser Ansatz sieht eine Bereitstellung von Ersatzpfaden vor, wobei keine vorausgehende Propagation von Änderungsnachrichten durch das ganze Netz erforderlich ist. Eine Änderung des Routings wird lediglich entlang von Ersatzpfaden vorgenommen. Diese beschränkte Um- Stellung des Routings erlaubt eine schnelle Reaktion auf
Störungen. Bei andauernden Störungen (persistent error) kann zusätzlich eine Topologieanpassung im Netz mittels des BGP-Protokolls durchgeführt werden.
Die Erfindung hat zur Aufgabe, die Reaktion von paketbasierten Netzen auf Störungsmeldungen effizienter zu gestalten.
Die Aufgabe wird durch ein Verfahren nach Anspruch 1 gelöst.
Die Erfindung beruht auf der Erkenntnis, dass vielfach Technologien bzw. Protokolle mit Störungserkennungs- und Stö- rungsbehebungsmechanismen simultan eingesetzt werden, die zu separaten, voneinander unabhängigen Reaktionen führen. Dabei können diese Reaktionen auf unterschiedlichen Zeitskalen ablaufen und in der resultierenden Netzbelastung stark differieren. Die Erfindung zielt darauf ab, langsame und aufwändige Stö- rungsbehebungsmechanismen zu unterdrücken, wenn ein parallel eingesetzter Mechanismus zu einer Fehlerbehebung führt oder wenn der Fehler von so kurzer Dauer ist, dass eine Behebung auf der Zeitskala des Störungsbehebungsmechanismus nicht sinnvoll ist.
Beispielsweise wird das hinsichtlich der Fehlerbehebung schwerfällige BGP Protokoll mitunter zusammen mit dem OSPF Protokoll oder dem MPLS (multi protocol label switching) Protokoll verwendet. Beide Protokolle haben Mechanismen zur Fehlerbehebung mit einer im Vergleich zum BGP Protokoll schnelleren Reaktionszeit. Die Erfindung zielt auf derartige Konstellationen .
Erfindungsgemäß reagiert eine Routinginstanz auf eine Meldung der Nichterreichbarkeit einer Nachbar-Routinginstanz bzgl. des Routens mittels eines Routingprotokolls durch Senden einer
Testnachricht an die Nachbar-Routinginstanz, um die Nichterreichbarkeit bzw. den Verlust der Konnektivität zu überprüfen. Erst wenn auch auf die Testnachricht keine positive Rückmeldung bzgl. der Erreichbarkeit erfolgt, wird eine Änderung des Routings zur Vermeidung der ausgefallenen Verbindung zu der Nachbar-Routinginstanz veranlasst. Der Begriff „Nachbar-Routinginstanz" ist dabei so zu verstehen, dass es sich im Sinne des Routingprotokolls um einen Nachbarn oder „next hop" handelt. Eine Nachbarschaft bzgl. der physikalischen Kommunikationsinfrastruktur muss nicht notwendigerweise vorliegen. Eine Nachbar-Routinginstanz kann beim In-
ter-Domänen-Routing auch ein benachbartes autonomes System bezeichnen .
Die Erfindung führt zu einem effizienteren Einsatz der vor- handenen Ressourcen bei der Fehlerbehebung. Eine Fehlerbehebung bzw. eine Änderung des Routings mittels des Routingprotokolls wird in drei wichtigen Fällen vermieden, bei denen eine derartige Änderung nicht erforderlich ist:
• Der Fehler besteht in einer kurzzeitigen Instabilität, die beim Senden der Testnachricht schon nicht mehr besteht. Derartige Instabilitäten können den Routingkonver- genzprozess anstoßen, was insbesondere bei BGP eine globale (im Sinne des Internets) Belastung des Netzes durch Up- date-Nachrichten nach sich zieht.
• Der Fehler wurde zum Zeitpunkt des Sendens der Testnachricht bereits von einem parallel verwendeten, auf einer schnelleren Zeitskala reagierenden Mechanismus behoben.
• Der Fehler wurde durch eine Fehlermeldung vorgetäuscht, um das System zu stören.
Nichterreichbarkeit kann beispielsweise mittels der Testnachricht festgestellt werden, indem ein Zeitintervall für eine Antwort (z.B. gespiegelte Testnachricht) vorgegeben wird und bei Ausbleiben der Antwort innerhalb des Zeitintervalls von der
Nichterreichbarkeit ausgegangen wird. Das Zeitintervall kann den Gegebenheiten des Systems (z.B. gemessene Verzögerungszeiten, verkehrstypbezogene Anforderungen bzgl. der Reaktionszeit auf Fehler) angepasst werden. Alternativ könnten protokollinhärente Fehlermeldungen bei der Übertragung der Testnachricht verwendet werden. Beispielsweise meldet das TCP (transport control protocol) , wenn ein Übertragung nicht erfolgreich ist. Ein derartiges Vorgehen ist aber in der Regel weniger flexibel.
Die Erfindung kommt vorzugsweise beim Inter-Domänen-Routing zum Einsatz, wo das Problem einer vergleichsweise langsamen Reaktion von EGP Protokollen und eine größere Gefahr von manipulierten Meldungen besteht. Bei Bestätigung des Fehlers würde beispielsweise eine Reaktion durch das EGP Protokoll (in der Regel BGP) erfolgen. Gemäß einer Weiterbildung wird die Erfindung mit der in der EP 1453250 beschriebenen Vorgehensweise kombiniert. Dabei wird von durch die Störung unterbrochenen Pfaden, welche zu traversierende autonome Systeme beinhalten, ausgegangen. Es erfolgt dann die Inbetriebnahme eines Ersatzpfades zu einem Zielpunkt. Zu diesem Zweck werden auf dem Ersatzpfad liegende Routing-Domänen benachrichtigt. Die benachrichtigte Routing-Domänen, die auf dem Ersatzpfad liegen, stellen ihr In- ter-Domänen-Routing entsprechend eines Routings zu dem Zielpunkt entlang des Ersatzpfades einstellen ein, bis alle Routing-Domänen auf dem Ersatzpfad ihr Inter-Domänen-Routing entsprechend einem Routing auf dem Ersatzpfad zu dem Zielpunkt eingestellt haben. Diese Vorgehensweise minimiert die beim Routing vorgenommenen Änderungen. Eine aufwändigere Anpassung der Gesamttopologie kann erfolgen, wenn sich der Fehler als ein dauerhafter erweist (persistent error) .
Das Verfahren kann aber ebenso gut innerhalb eines autonomen Systems bzw. für Intra-Domänen-Routing eingesetzt werden.
Fehlerreaktionen können dabei in einer netzweiten Topologie- änderung (z.B. OSPF) , in der Bereitstellung von einem Ersatzpfad für einen ausgefallenen Pfad (z.B. im Rahmen des MPLS-Konzepts) oder in einer lokalen Reaktion (z.B. wie in der WO2004/051957 beschrieben) bestehen.
Die Erfindung umfasst auch eine Vorrichtung, z.B. Router, welche eine Routinginstanz umfasst und für die Durchführung eines erfindungsgemäßen Verfahrens zur effizienten Behandlung von
Störungen bei der paketbasierten Übertragung von Verkehr ausgestaltet ist. Dabei kann eine Routinginstanz sowohl durch einen Router als auch eine Softwareimplementierung von Routingfunktionen auf geeigneter Hardware gegeben sein.
Im Folgenden wird der Erfindungsgegenstand im Rahmen eines Ausführungsbeispiels anhand von Figuren näher beschrieben. Es zeigen:
Fig. 1: Einen Ausschnitt aus einer Routingarchitektur
Fig. 2a und 2b: Einen Protokollstapel mit verschiedenen Mechanismen zur Fehlerbehebung
Fig. 1 zeigt schematisch das Zusammenwirken eines Moduls oder einer Protokollinstanz APCS (ACPS: adjacent peer check Service) mit einer Routingprotokollschicht (Routing Protocol Engine) RPE, welche miteinander über eine dafür vorgesehene Schnittstelle APCI (adjacent peer check interface) kommunizieren. Eine derartige Routingarchitektur wurde beispielsweise in dem in der Beschreibungseinleitung zitierten Dokument „Improving Con- vergence Time of Routing Protocols" von G. Lichtwald, U. Walter und M. Zitterbart verwendet. Das Routingprotokoll ist z.B. das BGP Protokoll. Das BGP Protokoll sieht periodische KEEPALIVE-Nachrichten mit einer Periode von üblicherweise 60 Sekunden zum Testen der Konnektivität vor. Bei Nichtzustell- barkeit von KEEPALIVE-Nachrichten erfolgt eine Fehlermeldung. Erfindungsgemäß würde dann über die Schnittstelle APCI die Protokollinstanz APCS dazu veranlasst, eine Testnachricht oder Check-Nachricht zu senden.
In Fig. 2a und 2b sind verschiedene Schichten eines Netzwerks dargestellt. Die unterste Schicht ist MPLS (multiprotocol label switching) . Basierend auf den MPLS-Pfaden wird eine logische IP-Topologie etabliert. Diese Topologie ist nicht gleich der MPLS-Topologie und „sieht" weniger Netzwerkkomponenten, d.h. ein Teil der auf der MPLS-Ebene aktiven Netzwerkkomponenten sind auf
der IP-Ebene transparent. Der BFD-Dienst (BFD: Bidirectional Forwarding Detection) basiert in diesem Beispiel auf der Sicht der IP-Schicht. Für das Border Gateway Protokoll sind die zwei redundanten Pfade der IP-Schicht transparent. Das BGP Protokoll „sieht" nur die direkte Session mit seinem BGP-Nachbarn.
In diesem Beispiel wird angenommen, dass der ausgefallene Link in Fig. 2b derjenige Link ist, über den die BGP Session etabliert war. Das BFD Protokoll meldet den Ausfall im Sub-Sekundenbereich an den BGP-Router. Herkömmlich führt dies dazu, dass das BGP Protokoll den Konvergenzprozess startet.
Beim Einsatz des hier beschriebenen Mechanismus wird der Konvergenzprozess nicht zwingend notwendig, da das BGP Protokoll vor dem Initiieren des Konvergenzprozesses mittels der
Check-Nachricht bei seinem BGP-Nachbarn prüft, ob dieser tatsächlich nicht mehr erreichbar ist. Moderne MPLS Versionen erlauben ein im Vergleich zur BGP Fehlerreaktion schnelles Umschalten auf Ersatzpfade. Die Check-Nachricht stellt in diesem Fall Konnektivität fest, weil durch die schnellere MPLS-Reaktion eine Fehlerreaktion vorhergegangen ist. Der BGP Mechanismus zur Fehlerbehebung wird dann nicht ausgelöst.
Hierdurch kann die Last im Internet signifikant gesenkt werden. Des Weiteren ist es möglich, mit diesem Mechanismus fälschlicherweise oder in missbräuchlicher Weise als nicht verfügbar propagierte Links zu erkennen und so ein beispielsweise das Hijacken - also das unautorisierte Aneignen eines Datenpfads - einer Route zu verhindern.
Claims
1. Verfahren zur effizienten Behandlung von Störungen bei der paketbasierten Übertragung von Verkehr mittels eines Rou- tingprotokolls und Routinginstanzen, bei dem a) einer Routinginstanz bezüglich dem Routing mittels des
Routingprotokolls die Nichterreichbarkeit einer Nachbar-Routinginstanz gemeldet wird, b) durch die Routinginstanz zur Überprüfung der Erreichbarkeit das Senden einer Testnachricht an die Nachbar-Routinginstanz veranlasst wird, c) bei Bestätigung der Nichterreichbarkeit im Zuge der Überprüfung auf einen Ausfall der Verbindung zu der Nachbar-Rou- tinginstanz geschlossen wird, und d) durch die Routinginstanz bei bestätigter Nichterreichbarkeit der Nachbar-Routinginstanz eine Änderung des Routings zur Vermeidung der ausgefallenen Verbindung veranlasst wird.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass
- ein Zeitintervall für eine Antwort auf die Testnachricht gegeben ist, und
- bei Nichterfolgen der Antwort innerhalb des Zeitintervalls Nichterreichbarkeit der Nachbar-Routinginstanz festgestellt wird.
3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass - das Routingprotokoll ein Inter-Domänen-Routingprotokoll ist, und
- die Routinginstanzen Inter-Domänen-Routinginstanzen sind.
4 . Verfahren nach Anspruch 3 , dadu r ch ge ke nn z e i chne t , da s s
- die Pfade durch zu Zielen zu passierende Routing-Domänen gegeben sind.
5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass
- die Änderung des Routings in Form einer Pfadänderung durch
Inbetriebnahme eines Ersatzpfades zu einem Zielpunkt erfolgt, indem
— auf dem Ersatzpfad liegende Routing-Domänen benachrichtigt werden und
— benachrichtigte Routing-Domänen, die auf dem Ersatzpfad liegen, ihr Inter-Domänen-Routing entsprechend eines Routings zu dem Zielpunkt entlang des Ersatzpfades einstellen, bis alle Routing-Domänen auf dem Ersatzpfad ihr Inter-Domänen-Routing entsprechend einem Routing auf dem Ersatzpfad zu dem Zielpunkt eingestellt haben.
6. Verfahren nach einem der Ansprüche 3 bis 4, dadurch gekennzeichnet, dass
- die Änderung des Routings in Form einer Pfadänderung im Rahmen einer durch netzweite Propagation von Nachrichten veran- lassten Topologieänderung erfolgt.
7. Verfahren nach einem der Ansprüche 1 bis 2, dadurch gekennzeichnet, dass
- das Routingprotokoll ein Intra-Domänen-Routingprotokoll ist, und - die Routinginstanzen Intra-Domänen-Routinginstanzen sind.
8. Verfahren nach Anspruch 7, dadurch gekennzeichnet, dass - die Änderung des Routings in Form einer Pfadänderung durch Bereitstellen eines Ersatzpfades erfolgt.
9. Verfahren nach einem der Ansprüche 7 oder 8, dadurch gekennzeichnet, dass
- die Änderung des Routings in Form einer Pfadänderung im Rahmen einer durch Propagation von Nachrichten innerhalb der Domäne veranlassten Topologieänderung erfolgt.
10. Vorrichtung, insbesondere Router, die zu Durchführung eines Verfahrens nach einem der Ansprüche 1 bis 9 eingerichtet ist.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
DE102005025419A DE102005025419A1 (de) | 2005-06-02 | 2005-06-02 | Verfahren zur effizienten Behandlung von Störungen bei der paketbasierten Übertragung von Verkehr |
PCT/EP2006/062810 WO2006128895A1 (de) | 2005-06-02 | 2006-06-01 | Verfahren zur effizienten behandlung von störungen bei der paketbasierten übertragung von verkehr |
Publications (1)
Publication Number | Publication Date |
---|---|
EP1897341A1 true EP1897341A1 (de) | 2008-03-12 |
Family
ID=36636221
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP06763437A Withdrawn EP1897341A1 (de) | 2005-06-02 | 2006-06-01 | Verfahren zur effizienten behandlung von störungen bei der paketbasierten übertragung von verkehr |
Country Status (5)
Country | Link |
---|---|
US (2) | US20090016213A1 (de) |
EP (1) | EP1897341A1 (de) |
CN (1) | CN101248648A (de) |
DE (1) | DE102005025419A1 (de) |
WO (1) | WO2006128895A1 (de) |
Families Citing this family (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7852778B1 (en) | 2006-01-30 | 2010-12-14 | Juniper Networks, Inc. | Verification of network paths using two or more connectivity protocols |
US7738367B1 (en) * | 2006-08-29 | 2010-06-15 | Juniper Networks, Inc. | Performing non-revertive failover with network devices |
US7860981B1 (en) * | 2006-09-29 | 2010-12-28 | Juniper Networks, Inc. | Systems and methods for IP session keepalive using BFD protocols |
CN101087211B (zh) * | 2007-07-20 | 2010-08-11 | 华为技术有限公司 | 一种实现bfd机制中回声功能的方法及系统及功能实体 |
CN103378927B (zh) * | 2012-04-20 | 2019-01-11 | 中兴通讯股份有限公司 | 数据发送方法及装置 |
CN102769573B (zh) * | 2012-08-01 | 2014-11-05 | 杭州华三通信技术有限公司 | 借助bfd报文实现bgp保活信息发送的方法及路由设备 |
US8902780B1 (en) | 2012-09-26 | 2014-12-02 | Juniper Networks, Inc. | Forwarding detection for point-to-multipoint label switched paths |
US9258234B1 (en) | 2012-12-28 | 2016-02-09 | Juniper Networks, Inc. | Dynamically adjusting liveliness detection intervals for periodic network communications |
US8953460B1 (en) | 2012-12-31 | 2015-02-10 | Juniper Networks, Inc. | Network liveliness detection using session-external communications |
CN104702478B (zh) * | 2013-12-10 | 2019-06-11 | 中兴通讯股份有限公司 | 虚拟路由转发实例处理方法及装置 |
US9769017B1 (en) | 2014-09-26 | 2017-09-19 | Juniper Networks, Inc. | Impending control plane disruption indication using forwarding plane liveliness detection protocols |
US10374936B2 (en) | 2015-12-30 | 2019-08-06 | Juniper Networks, Inc. | Reducing false alarms when using network keep-alive messages |
US10397085B1 (en) | 2016-06-30 | 2019-08-27 | Juniper Networks, Inc. | Offloading heartbeat responses message processing to a kernel of a network device |
US11750441B1 (en) * | 2018-09-07 | 2023-09-05 | Juniper Networks, Inc. | Propagating node failure errors to TCP sockets |
Family Cites Families (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP3454297B2 (ja) * | 1995-04-10 | 2003-10-06 | インターナショナル・ビジネス・マシーンズ・コーポレーション | ネットワーク・スイッチ間のリンクをテストするための方法および装置 |
US6668282B1 (en) * | 2000-08-02 | 2003-12-23 | International Business Machines Corporation | System and method to monitor and determine if an active IPSec tunnel has become disabled |
US7035202B2 (en) * | 2001-03-16 | 2006-04-25 | Juniper Networks, Inc. | Network routing using link failure information |
EP1394985A1 (de) * | 2002-08-28 | 2004-03-03 | Siemens Aktiengesellschaft | Testverfahren für Nachrichtenpfade in Kommunikationsnetzen sowie Netzelement |
EP1453250A1 (de) * | 2003-02-28 | 2004-09-01 | Siemens Aktiengesellschaft | Verfahren zur schnellen Reaktion auf Linkausfälle zwischen verschiedenen Routing-Domänen |
US7746793B2 (en) * | 2004-06-18 | 2010-06-29 | Cisco Technology, Inc. | Consistency between MPLS forwarding and control planes |
US7515529B2 (en) * | 2004-12-14 | 2009-04-07 | Cisco Technology, Inc. | Efficient mechanism for fast recovery in case of border router node failure in a computer network |
-
2005
- 2005-06-02 DE DE102005025419A patent/DE102005025419A1/de not_active Ceased
-
2006
- 2006-06-01 WO PCT/EP2006/062810 patent/WO2006128895A1/de active Application Filing
- 2006-06-01 EP EP06763437A patent/EP1897341A1/de not_active Withdrawn
- 2006-06-01 US US11/916,076 patent/US20090016213A1/en not_active Abandoned
- 2006-06-01 CN CNA2006800191036A patent/CN101248648A/zh active Pending
-
2010
- 2010-03-10 US US12/721,226 patent/US20100254256A1/en not_active Abandoned
Non-Patent Citations (1)
Title |
---|
See references of WO2006128895A1 * |
Also Published As
Publication number | Publication date |
---|---|
DE102005025419A1 (de) | 2006-12-07 |
CN101248648A (zh) | 2008-08-20 |
WO2006128895A1 (de) | 2006-12-07 |
US20090016213A1 (en) | 2009-01-15 |
US20100254256A1 (en) | 2010-10-07 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
WO2006128895A1 (de) | Verfahren zur effizienten behandlung von störungen bei der paketbasierten übertragung von verkehr | |
EP1597877B1 (de) | Verfahren zur schnellen reaktion auf linkausfälle zwischen verschiedenen routing-domänen | |
EP1897292B1 (de) | Verfahren zur bereitstellung von ersatzwegen als schnelle reaktion auf den ausfall eines links zwischen zwei routing-domänen | |
WO2006128894A1 (de) | Verfahren zur bereitstellung von ersatzwegen als schnelle reaktion auf den ausfall eines links zwischen zwei routing-domänen | |
EP1532771B1 (de) | Testverfahren f r nachrichtenpfade in kommunikationsnetzen s owie netzelement | |
DE102007015539B4 (de) | Verfahren zum Rekonfigurieren eines Kommunikationsnetzwerks | |
WO2005013564A1 (de) | Verfahren für ein inter-domain mehrwege-routing | |
DE102007015449B4 (de) | Verfahren zum Rekonfigurieren eines Kommunikationsnetzwerks | |
US7359992B2 (en) | Method of preserving symmetrical routing in a communication system based upon a server farm | |
EP1566039A1 (de) | Verfahren zur umleitung von datenpaketen bei lokal erkannten linkausfällen | |
WO2005011206A1 (de) | Verfahren und netzknoten zur meldung mindestens eines ausgefallenen verbindungsweges innerhalb eines kommunikationsnetzes | |
EP1665656A1 (de) | Verfahren zur optimierten deaktivierung von inter-domain routen | |
DE102023126376A1 (de) | Beschleunigung der korrektur von wan- oder lan-datenverkehrsverlusten | |
WO2005034442A1 (de) | Schnelle fehlerreaktion in lose vermaschten ip-netzen | |
DE102005046397B4 (de) | Verfahren zum raschen Auffinden günstiger Link-Kostenmetriken nach Netzwerkfehler | |
WO2006097395A1 (de) | Verfahren und system zum betrieb redundanter netzelemente in einem kommunikationsnetz | |
WO2004066568A1 (de) | Verfahren zur umleitung von datenpaketen bei lokal erkannten linksausfällen durch mehrfachwegefindung | |
WO2006094879A1 (de) | Überwachungssystem für ein kommunikationsnetz (ipn) zur eindeutigen erkennung der zerstörung eines netzwerkelementes (mgc) | |
EP1394987A1 (de) | Redundante Netzwerkanordnung |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
17P | Request for examination filed |
Effective date: 20080102 |
|
AK | Designated contracting states |
Kind code of ref document: A1 Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR |
|
DAX | Request for extension of the european patent (deleted) | ||
17Q | First examination report despatched |
Effective date: 20080826 |
|
RAP1 | Party data changed (applicant data changed or rights of an application transferred) |
Owner name: NOKIA SOLUTIONS AND NETWORKS GMBH & CO. KG |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN |
|
18D | Application deemed to be withdrawn |
Effective date: 20160105 |