WO2005013563A1

WO2005013563A1 - Method for the fast detection of faults in ip networks

Info

Publication number: WO2005013563A1
Application number: PCT/EP2004/051488
Authority: WO
Inventors: Gero Schollmeier; Thomas Schwabe; Christian Winkler
Original assignee: Siemens Aktiengesellschaft
Priority date: 2003-07-29
Filing date: 2004-07-14
Publication date: 2005-02-10
Also published as: DE10334632A1

Abstract

According to the invention, the network nodes (routers) exchange keep-alive messages among each other in addition to the routing data in order to recognize disturbances on the transmission paths between the network nodes, the rhythm at which the keep-alive messages are exchanged being greater by at least one order of magnitude than the rhythm at which the routing data is exchanged. The fault reaction time is shortened by separating the routing process and the handling of faults in the IP network. The fault detection time can typically be accelerated approximately one thousand times.

Description

2003 P 11273

description

Procedure for fast error detection in IP networks

The subject matter of the application relates to a method for identifying interference on the transmission path between network nodes of a packet-oriented data network in which neighboring network nodes exchange routing information with one another.

In today's IP (Internet Protocol) networks, line and node failures generally lead to longer interruptions in the flow of traffic (in the order of tens of seconds to minutes). Should real-time services, e.g. This error behavior is not sufficient with the language with which the usual quality for telecommunications services is routed through these networks. This requires reaction times well below one second.

In today's IP networks, line and node failures are generally recognized by the routing protocols and eliminated by network-wide calculation of new routes. Adjacent routers exchange status information at regular intervals, the repeated absence of which is considered an error and triggers a recalculation of the routes. With today's routing protocols, this "error detection" works so slowly (e.g. with OSPF with so-called "Hello Messages" approx. 40 seconds) that despite the following re-routing serious traffic problems occur.

A simple acceleration of these hello messages is not possible. The minimum times are specified in the standard and can therefore not be exceeded in existing routers. The reason for this is that as a result of missing Helios extensive table transfers or calculations are triggered, which is already the case with today's low ones

Repetition frequencies is disruptive. In addition, 2003 P 11273

2 reduction of the times the danger of unstable operating conditions in the

Network.

In addition to the error detection of the routing protocols, modern routers also offer interface error detection, which evaluates the absence of the physical signal as an error and reports it to the routing process. This error detection reacts much faster, but can only detect errors in the line section directly connected to the router. If, as is often the case with networks, there are further transmission facilities between neighboring routers, only the edge sections are secured with this method and only the "gross" errors of a complete physical failure are recognized.

The object of the application is based on the task of specifying a method which brings about a shortened error reaction time in the event of a transmission path failure.

The object is solved by the features of claim 1.

The handling of errors in the IP network, which is not possible in this form today, allows the development and use of flexible error detection mechanisms and error reactions. With the Alive mechanism, errors are quickly identified and, ideally, can be dealt with locally immediately. Impairment of ongoing communication relationships through (proportionately prevalent) link failures is largely avoided.

The error detection time can typically be accelerated by a factor of around 1000.

Advantageous further developments of the subject of the application are specified in the subclaims. 2003 P 11273

3 The subject of the application is explained in more detail below as an exemplary embodiment to the extent necessary for understanding on the basis of a figure.

The network nodes NK 1 .. NK9 (router) in FIG. 1 form a packet-oriented data network (IP network) with the transmission paths connecting them (left, routes).

The invention makes use of the knowledge that the close coupling of "error detection", which is actually intended as "topology detection", with routing, ie route calculation, is problematic for error handling in today's IP networks.

A) Separation of the routing process from error detection / error reaction

Routing and error detection / error reaction are separated in order to be able to develop and use flexible and comprehensive error handling mechanisms. In contrast to the mechanisms described at the outset, which directly change the routing, the separate error detection process in the router can now react specifically to a detected error. For example, if the network is working with multipath routing, it can redirect the traffic locally in the router in question without triggering the network-wide reactions described at the beginning.

B) Error detection at the IP level

Through additional alive messages to be introduced between neighboring routers at intervals Ta of a few ms, which are exchanged on each line, the error detection time is accelerated by a factor of about 1000. These alive messages are not linked to the router process, but are evaluated separately in an error handling process (which can also be implemented distributed in the router in practical implementation). 2003 P 11273

4 Each router sends these alive messages on each line in a uniform clock Ta. At the same time, he checks on each line whether he receives corresponding messages from his neighbor at a distance Ta. If N of these messages remains in succession (or determined according to some other statistical function, for example), the router's error handling declares the line as interrupted (or as inaccessible to the neighbors) and in turn stops the transmission of the alive messages for this line. If these alive messages are sent as IP packets (with the appropriate identification, e.g. by the IP address or a special protocol number), it is possible to secure the entire route between the neighboring routers across all transmission technology facilities. In addition, a part, with appropriate implementation in the router may be even very largely, the router's internal IP treatment functions are secured.

C) Error handling process In addition to the alive messages, other signals and events can also be added to the error handling process. For example, the error signals of the physical interfaces as described at the beginning. Or any error signals that the router generates internally to monitor its own function. The more information the error handling process receives, the better it can react to the error. He can also interact with the routing process, both to obtain information from the routing process (e.g. about the topology of the network) and to stimulate the routing process to recalculate the route.

In a practical implementation in a modern router, one would integrate alive generation and reception on the line cards in the data path. This would at least implement this part of the error handling process in a distributed manner.

D) Error communication 2003 P 11273

5 In addition to the alive messages (see B), the error handling processes of different routers can optionally also exchange further information on error handling. This can take the form of separate messages (between neighboring routers or even between remote routers) or embedded in the alive messages (between neighboring routers). Applications could e.g. the signal from a router NK 7 to its neighboring router NK 6, NK 6 should no longer send traffic to NK 7 to a specific destination NK 8, since NK 7 has detected an interruption in its route to NK 8.

Claims

2003 P 11273 patent claims

1. A method for identifying faults on the transmission path between network nodes (NK) of a packet-oriented data network, consequently adjacent network nodes exchange routing information with one another, characterized in that a network node periodically sends alive messages to an adjacent network node and alive periodically transmitted by the neighboring network node -Messages receives

the period Ta with which the alive messages are exchanged is at least one order of magnitude smaller than the period with which the routing information is exchanged between the adjacent network nodes

- If there is no predetermined number of alive messages, the network node detects a fault in the transmission path to the neighboring network node.

2nd A method according to claim 1 d a d u r c h g e k e n n z e i c h n e t that the period Ta is a few milliseconds.

3. The method according to any one of the preceding claims, characterized in that the alive messages are given by IP (Internet Protocol) packets with special identification.

4. The method according to any one of the preceding claims, characterized in that an IP packet identified as an alive message contains information for error handling.

5. The method according to any one of the preceding claims, characterized in that 2003 P 11273

7 the generation and reception of alive messages is integrated on the line cards in the data path.

6. The method according to any one of the preceding claims, characterized in that the network node forwards the data packets to be forwarded to an alternative transmission path provided when a fault in the transmission path is detected.

7. The method according to any one of the preceding claims, characterized in that a network node sends alive messages on each line and checks whether it receives corresponding messages from its respective neighbor at a distance Ta.

8. The method according to any one of the preceding claims, characterized in that the error handling processes of different network nodes, in particular also not immediately adjacent, exchange information for error handling.