This application is the US National Stage of International Application No. PCT/EP2004/050950, filed May 27, 2004 and claims the benefit thereof. The International Application claims the benefits of German application No. 10324604.5 DE filed May 30, 2003, both of the applications are incorporated by reference herein in their entirety.
The invention relates to a method for routing IP packets to an external control component of a network node in an IP packets switching communications network.
Internet protocol networks (IP networks for short) will in future transport higher-quality services in addition to the current standard Internet and best-effort services, and will permit new applications. To this end enhancements to the control of the network nodes of an IP network or of the network controller are necessary, e.g. for administering the network resources or for fast reconfiguration in the event of errors.
In general the alternatives are to:
The first integrated solution has the advantage that internal information in the network component is available to the control component thanks to the close link to the network component.
In contrast to this an “add-on” solution is vendor-independent and more flexible, precisely because it is not so closely interwoven with the internal aspects of the network component. In addition, “add-on” solutions can be based on standard hardware (HW for short) and software (SW for short) solutions, while network components such as routers are mostly based on proprietary HS/SW solutions. Shorter development cycles and cost savings can be achieved with “add-on” control components. The drawback of “add-on” solutions is that internal information in the network component is not available.
Using the example of an admission control (AC for short) component the problem of the second, external, “add-on” server solution is illustrated below.
One object of admission control is to accept incoming resource queries, compare them with resources still available and if resources are still available to program a network node or router, e.g. the router on the edge of the network (edge router) for control of the data flow. This includes setting what are known as functions, such as marking, filtering and policing.
The following two questions arise here, among others:
In principle, there are two variant solutions for A):
The following is based exclusively on signaling in accordance with variant 2), in other words in-band signaling.
The standardized resource reservation protocol RSVP is an in-band signaling protocol. It solves the questions outlined above as described under point 2) and performs a hop-by-hop reservation in the network node. The key point here is that the RSVP instance is implemented in the router itself and hence can operate with the router and its internal aspects on a very close-meshed basis.
Using the example of an RSVP-capable network, i.e. of a network with RSVP-capable network nodes or routers in accordance with
The user X generates a resource request to the network for a data flow to user Y. It must be ensured here that the resource reservations in the network nodes are also in fact undertaken along the subsequent data path. In IP networks this data path depends on the current routing. Hence in the resource reservation protocol RSVP the resource request is sent into the network with the IP destination address, in other words the IP address of the user Y. It thus automatically follows the data path of the subsequent data flow to user Y. Although these RSVP messages are now not addressed to the RSVP control components AC or RSVP instances, the RSVP control components AC or RSVP instances of the network nodes lying on the path must be notified of them.
Hence these messages are specially marked by the defined IP protocol type “RSVP” in the IP header, in other words in the header of an IP packet.
The routers identify this protocol type and route messages marked in this way directly to their RSVP instance, in other words to the control component AC.
Later, in the course of the procedure, the RSVP instance must configure “its” edge router A on the edge of the network to user X (filtering, marking, policing). In concrete terms, the interface to be configured is the one via which the RSVP message was originally received from user X and via which the data flow from user X to user Y will subsequently arrive. Since the RSVP instance is implemented in the router, it can interrogate this internal information.
The solution for the two points A and B lies here in the close internal link between network node and control component.
In the case of external control components the problem exists that this internal information is not interrogated in the case of the network node or made available by the network node. A further problem exists if the external control components of the network node are not provided thereto directly, but are located at a very remote place in the network and can only be reached via a network connection.
An object of the present invention is to specify a method in which received IP packets can be routed with interface information in the receiving node to an external control component.
This object is achieved by methods in accordance with the features in the claims.
The advantage of the invention is that IP packets are routed with network-node-internal control information to an external control component. As a result a control component “added on” to a network node can assume comprehensive control tasks of the network node.
Another advantage is that the external control component can be disposed at a remote location in the network and is connected via a network connection.
Advantageous developments of the invention are specified in the d.
Brief Description Of The Drawings An embodiment of the invention is illustrated in the drawing and is explained in the following.
The drawings show:
Analogously to the example referred to in the introduction to the description, data packets are to be transferred from user X to user Y. The external control components AC here require particular IP packets, such as in-band IP signaling packets, for example RSVP packets, and the information about which interface of the network node the IP packet/in-band IP signaling packet/RSVP packet was received at. The latter information is only available internally in the network node and cannot be interrogated. The routing tables of the network node or router contain only information about destinations, but not about where a packet came from.
To solve the problem, rules are configured on the interfaces of the network nodes. Current network nodes or routers support what is known as policy routing, whereby rules can be configured for how to deal with special packets. Moreover, use is made of what is known as tunneling.
Using IP tunnels, e.g. GRE tunnels, the original IP packet is supplemented at the tunnel entrance by a tunnel header including a tunnel ID and a new external IP header. The IP packet is routed through the network with this IP header. At the end of the tunnel the external header is removed again and the original packet is further processed.
Modern network nodes or routers, in particular the edge routers involved here, often support one or more variants of tunneling.
The solution using tunnels is based on the fact that several tunnels can be set up from the network node or router (start of the tunnel) to the control component AC or control instance (end point) and can be distinguished by their tunnel identification number (tunnel ID for short) in the tunnel header.
A first variant consists in using the tunnel ID to transfer internal information. Thus for each interface of the network node a separate tunnel is set up to the control component, so that the interface number corresponds explicitly or implicitly to the tunnel ID.
To this end a tunnel is set up from each interface of the network node to the control component. To do this, a rule is set up in the network node or on the interface, that particular IP packets, such as in-band IP signaling packets which are marked by an entry in the protocol field of the IP header of the IP packet, are packed in a second, “external” IP packet, the IP address of the control component assigned to the network node is entered as the destination IP address in the “external” IP packet and a value unambiguously assigned to the interface which differs from the values of the other interfaces of the network node and with which the interface can be unambiguously identified, is entered as a tunnel ID in the “external” IP packet. This packet is forwarded by the IP routing to the control component. In similar fashion, in-band IP signaling packets of the type “RSVP” are packed and transmitted.
The advantage of this tunnel solution is that the control components or control instances need not be connected directly to the network node or router, but can be positioned anywhere in the network, as illustrated in
In a parallel patent application by the applicant a solution for a similar object is proposed using what is known as DSCP marking. In the case of a particular received IP packet, such as an in-band IP signaling packet of the type “RSVP”, the value of a particular field, such as the DSCP field, the IP header or header field of the IP packet, is here changed and a value dependent on the receiving interface of the network node is entered into the particular header field/DSCP field. This solution can be combined with the tunnel solution. Thus tunnels can be set up and in addition the DSCP fields of an IP packet can be modified.
The rules on the interfaces of the network nodes then contain a corresponding marking, such as DSCP marking, and the corresponding tunnel as the “next-hop” entry.
In the following the DSCP field is assumed to be the field to be changed, but another field in the header of the IP packet can also be used.
If DSCP marking and tunneling is used, a DSCP field change or a DSCP marking should be undertaken on the internal IP header. The external IP header can then actually be used for DSCP priority marking.
Moreover the tunnel ID need no longer contain a value assigned to the interface, since this value is unambiguously entered into the DSCP field.
In addition there is no need for a tunnel to the assigned control component to be set up from every interface. Thus at least one tunnel to the control component could be set up from the network node, whereby all IP packets of a particular type, such as in-band IP signaling packets, e.g. “RSVP” packets, are transmitted to the control component and the distinction as to which interface the packet was received at is made by the changed DSCP field.
Since the DSCP field is 6 bits in size, permitting a range of 64 values, the available value range is increased by a combination of tunneling and DSCP marking. As a result a large range can be covered with few tunnels. Using e.g. 2 tunnels and DSCP marking it is thus possible to distinguish 128 values or interfaces of the network node.
Tunneling can also be achieved by multiprotocol label switching, MPLS for short. The method is analogous to IP tunnels, with the difference that MPLS “tunnels” or MPLS paths are used instead of the IP tunnels.
With multiprotocol label switching, MPLS for short, states are maintained network-wide which define the routes or paths on which packets are routed through the network circumventing the “normal” IP routing. The network nodes here no longer route packets on the basis of the destination IP addresses, but a bit sequence, known as a label, is attached to each packet on entrance to the network. This label, which is evaluated in every network node, determines the route on which the packets are forwarded. The correlation between labels and paths must be created when the network is commissioned. The label is removed again at the network exit. In addition local mechanisms or rules are required to divert packets onto a backup path if the path originally envisaged crashes, or to establish a backup path after a crash.
An in-band IP signaling packet or an IP packet of the type “RSVP”, or of another type, received at an interface of the network node is identified here and an MPLS label is prefixed to the packet, the label ID of which is unambiguously assigned to the receiving interface and leads to the control component assigned to the network node. The IP packet packed in this way is routed to the control component by means of MPLS. The MPLS label ID prefixed to the IP packet is evaluated in the control component and the interface on which the IP packet was received from the network node is determined in the control component.
On the interface of the network node the rule is implemented that a particular value, permanently defined for the interface, is prefixed to the IP packet as an MPLS label and the packet is routed using MPLS. Using the MPLS method it must be ensured that packets with a particular MPLS label ID lead to the corresponding destinations, in this example to the control component.
In this case too MPLS can be combined with DSCP marking, in similar fashion to the method described above. Here it is sufficient if at least one MPLS label ID is entered in the network node, since the interfaces of the network node are distinguished by the DSCP marking.
For example, an in-band IP signaling packet or a packet of the type “RSVP” received at an interface of the network node is identified and is processed such that the value of a particular field, such as of the “DSCP” field, is changed as a function of the receiving interface. For example, an unambiguous interface ID, which differs from the interface ID of the other interfaces of the network node, is entered into the DSCP field, an MPLS label is further prefixed to the IP packet and this changed packet is routed by the MPLS method to the control component. It is not necessary here for every interface to enter a separate MPLS label ID, since the interfaces are distinguished by the DSCP field. Likewise large value ranges can be achieved by combining MPLS label ID and DSCP marking. Using e.g. 2 MPLS label IDs and DSCP marking it is possible to distinguish 128 values or interfaces of a network node.
Number | Date | Country | Kind |
---|---|---|---|
103 24 604.5 | May 2003 | DE | national |
Filing Document | Filing Date | Country | Kind | 371c Date |
---|---|---|---|---|
PCT/EP04/50950 | 5/27/2004 | WO | 11/30/2005 |