Patent Application
20050180433
The invention relates to a bandwidth controller, a network and an IP subnetwork management process for routing data within a network, and in particular the management of IP microflow routing within a subnetwork.
An IP microflow is an IP flow associated with a particular IP application and a transmitting terminal and receiving terminal. A microflow is determined by a group of 5 transported parameters (5-tuples): the IP protocol reference, the originating address, the destination address, the originating port number and the destination port number.
Currently, IP packet traffic within a subnetwork may be managed through MPLS (multiprotocol label switching), in other words a transmission technology used to allocate a label to an IP flow, providing information about the path that it must follow, so that it can be switched or routed more quickly on networks using different protocol types. This technology has a high granularity, however. Routers perform filtering according to rules predefined on activation of the subnetwork. The traffic is usually managed through filtering according to flow IP packet originating address ranges. Thus, if an originating site sends an IP packet flow considered to be important (for example, packets whose port numbers relate to a particular protocol that it has been decided to give priority to) the entire packet flow will follow the same path. This requires the allocating of resources (“size of pipes”) that are adequate for traffic estimations and the transport quality required. This technology is therefore likely cause to overloads on certain paths, which are undersized at a given time, or wastage if the paths are oversized at off peak times. The use of IP microflows, with contents such as voice or video implying technical constraints such as loss of packets, transmission times, or bandwidth, may be impaired by the slowing down of traffic due to overloads. Thus current routing management and traffic engineering processes do not allow sufficiently flexible routing. Furthermore, these processes do not guarantee a particular service quality according to the state of the network. This technology also does not permit the service quality associated with a microflow to be maintained on the closing of a path and the transferring of the total flow initially following this path to another path. Maintenance operations on the network, or faulty path elements, may therefore mean that path transferring/closing leads to service quality faults.
Bandwidth controllers are also available, such as those described by French patent application request publication number 2 835 987. Such a device provides a good level of granularity, taking into account microflows. However, it does not allow general information to be taken into account, in other words information concerning the network or subnetwork, which depend on several factors, such as contracts between service providers, the deployment of optimisation applications, etc.
There is therefore a need for a microflow management process and device that would resolve one or more of these disadvantages.
The invention first and foremost comprises a bandwidth controller able to communicate with at least one IP communication subnetwork routing element, characterised by the fact that it is also able to communicate with a network manager and:
According to one variant, the bandwidth controller also includes:
The invention also comprises a communication network consisting of:
According to one variant, the network manager is in possession of subnetwork state measurements, and the network manager's instructions depend on these measurements.
According to one variant, one of the network's routing elements is a subnetwork boundary router.
According to one variant, at least one routing element is a network address translator.
According to one variant, the bandwidth controller and the network manager are incorporated within the same network element.
Thirdly, the invention comprises a communication subnetwork management process including the following stages:
According to some variants,
The invention will now be described in more detail in below, and through reference to the single FIGURE, which illustrates an example of a communication network implementing the invention.
The invention proposes a process and a bandwidth module able to control the routing elements of an IP communication subnetwork, in order to set the routing of IP microflows according to rules defined by a network manager.
The FIGURE shows a communication network 1. This communication network comprises a transmitting terminal 2 in communication with a receiving terminal 3 by means of an IP subnetwork 4. The subnetwork consists of several routing elements 5 to 8 defining several routing paths between them. The routing elements 5 to 7 in the example are subnetwork boundary routers and the routing elements 6 and 8 are core routers of this subnetwork 4. The network elements 5 to 8 are controlled by a bandwidth controller 9. The bandwidth controller 9 is in communication with a network manager 10, also known as an NMS (Network Management System).
According to variants of the invention, the element referred to by the number 2 may be a server or another bandwidth controller (for example, associated with another subnetwork located upstream of the IP subnetwork 4).
The network manager 10 defines routing objectives and may bring together contextual data concerning the subnetwork. The network manager 10 has detailed knowledge of the network. The network may, for example, have been configured by the network manager 10. The role of the network manager 10 is to provide routing instructions to the bandwidth controller, particularly in situations where the controller needs to redirect flows.
For example, for flows needing to go from A to B, these routing instructions may be aimed at passing 60% of these flows through path A-C-B and 40% through path A-D-B. They may also target the use of a particular path up to a path use threshold percentage, above which flows are directed to other paths.
The network manager 10 thus provides microflow routing instructions according to the general routing rules at its disposal.
These rules are imposed, for example, by service quality contracts, concluded between a service provider who owns the subnetwork, and a customer who wishes to establish a traffic flow between terminals 2 and 3. They are referred to as service quality routing rules.
These rules may also be determined empirically according to the service provider's observations concerning traffic within the subnetwork. The rules may also be determined in order to reduce traffic costs, according to charging periods associated with certain routes.
Alternatively, the rules may be intended to share a microflow load within the subnetwork. For example, a request may be made for the distribution of video over IP traffic between several routes to avoid overloading a particular route within the subnetwork.
The bandwidth controller 9 is provided with instructions according to these rules, for example using a transport code compliant with the CORBA architecture (Common Object Requester Broker Architecture) defined by OMG (Open Management Group) and/or a SOAP protocol (Simple Object Access Protocol).
The bandwidth controller 9 processes the routing instructions provided by the network manager 10. The processing function includes, in particular, the saving of the routing instructions received by the bandwidth controller.
Furthermore, the network manager's routing instructions are preferably not specifically adapted to the subnetwork 4. They may be more wider ranging. These instructions can in this case be translated into commands specific to the subnetwork by the bandwidth controller 9, which may incorporate an instruction interpreter for this purpose.
The bandwidth controller 9 generates microflow routing commands according to the routing instructions. The bandwidth controller 9 can then send microflow routing commands to one or several of the subnetwork's elements. The bandwidth controller may generate routing commands specific to the subnetwork according to various data made available to it, for example in a database. These data might also be transmitted to the bandwidth controller 9 by the network manager 10. The bandwidth controller 9 may, for example, be in possession of information about the subnetwork's topology or of tables detailing the routing within this subnetwork 4. The bandwidth controller 9 may also have access to data relating to the subnetwork's context, such as the load on various of the subnetwork's paths, the packet loss rate (and more generally the service quality) on different subnetwork paths, or the instantaneous cost of a link within the subnetwork.
Depending on the type of instruction, the bandwidth controller may generate and send microflow routing commands to one of the subnetwork's elements, directly following the sending of specific instructions by the network manager, as will be discussed further on.
However, according to one variant, the network manager 10 sends instructions to the bandwidth controller 9, but the latter 9 only generates and sends microflow routing commands to a subnetwork element 5, 6, 7, 8 following a microflow routing request originating, for example, from a terminal 2, a server 2, or another bandwidth controller 2.
A typical scenario would be the following: a network manager 10 has provided instructions, based on a set of rules, to a bandwidth controller 10. A terminal 2 or a server 2 requests a service quality for a type or set of microflows to be transported (or routed) towards a client terminal 3. This request is transmitted to the bandwidth controller 9, which then generates and sends microflow routing commands to a subnetwork element 5, 6, 7, or 8, in order to ensure that the service quality requested is provided, while taking into account the instructions sent by the network manager 10.
The command generated by the bandwidth controller 9 is received by a network element and translated, in other words executed by this network element.
This network element may, for example, be a router or a network address translator (or NAT box, standing for Network Address Translation). In the following, however, we shall assume that the element is a router, for purposes of illustration. Note that some routers may have network address translator (NAT) functionalities.
The IP microflow routing is therefore carried out in a way specific to the subnetwork, according to general rules defined in the network manager 10. It is preferable to have this separation between the general routing rule definition function of the network manager 10 and the function that allows the applying of these routing rules by the bandwidth controller 9. This separation frees the bandwidth controller from determining routing rules and therefore improves routing element control.
Supposing that the network manager 10 in the FIGURE provides the bandwidth controller 9 with instructions to share the voice over IP microflow load within the subnetwork 4, the bandwidth controller will generate and send an appropriate command to the routing element 5 (for example following a routing request originating from a terminal 2, a server 2, or another controller 2). This command may request that the routing element 5 routes half of the voice over IP microflows originating from the terminal 2 along the path 5-6-7 and the other half of the voice over IP microflows along 5-8-7, the FIGUREs identifying the paths corresponding to the references of the network elements through which the microflows successively pass.
Let us also suppose that the network manager 10 has sent a “take the least expensive path for voice over IP microflows” request. Following a routing request originating from a terminal 2, a server 2, or another controller 2, the bandwidth controller 9 may, for example, determine that path 5-6-7 is the least costly, according to costing data in the possession of the controller 9, or that have been provided by the network manager 10. The bandwidth controller 9 in this case generates and sends, to router 5, a command to route voice over IP microflows only on path 5-6-7 between routers 5 and 7. The change in routing then takes place in a way that is transparent for the user.
The bandwidth controller 9 may also define routing commands for new microflows passing through the subnetwork 4. On the receiving of a new microflow on the router 5, the router 5 might therefore communicate certain of the microflow's properties, such as the microflow's protocol, the microflow's destination IP address, or any other property relevant to routing. Within the context of the present patent, the notion of “microflow routing request” may include the communicating by the router 5 of the properties above to the controller 9.
In addition, a microflow routing request originating from a terminal 2, a server 2, or any other controller 2, may itself indirectly originate (in other words pass through) from a router 5 that communicates it to the controller 9.
The bandwidth controller 9 in this case determines the microflow routing path(s) and generates a corresponding routing command. The router receives and executes this command. The new microflow may then take a path corresponding to the general rules of network manager 10 and/or, where applicable, to a request originating from a terminal 2, a server 2, or another controller 2. The changing of a new microflow's routing is therefore carried out in a way that is transparent for the user. The routing is thus performed according to the invention at microflow level, rather than aggregate level, according to the microflow's parameters. The routing can in this way be carried out with low granularity. The flexibility of the routing's management is improved, which in particular prevents overloads within the subnetwork. Different service qualities can also be provided for each microflow.
As mentioned above, the routing of an IP microflow within the subnetwork might also be modified by any appropriate means. For example, the use of network address translators might be considered for this purpose.
According to a variant, the functionalities of the bandwidth controller 9 and the network manager 10 may be combined within a single element, such as a rule server, or PDP (Policy Destination Point). The functionalities of the bandwidth controller 9 and the network manager 10 may, for example, be implemented in software form in a terminal communicating with the network elements 5 to 7.
Although in the FIGURE the bandwidth controller is shown communicating with the routing elements 5 to 8, it may of course be envisaged for the microflow routing commands to only be sent to an appropriate number of routing elements. This would mean that, for the whole of the FIGURE, the routing commands might only be sent to the boundary router 5 of the subnetwork 4.
One management process variant is aimed at making the closing of a path routing an IP microflow within a subnetwork transparent and predictable for a microflow user. According to this variant, the network manager 10 transmits instructions to the bandwidth controller 9. These instructions may, for example, contain a request for the suspending of a route or, more generally, for the changing of the service quality property for a route. This means that, following a request, a route may no longer be qualified for microflow traffic of a given type, for example voice. Maintenance might be carried out on the physical link between the routing elements 6 and 7, for example. A link might also be avoided by looking for cheaper routes at certain times. Supposing that this link provides the transferring of voice over IP microflows, the instructions may, for example, contain a request banning any new Voice over IP microflows on this link. By way of example, a new telephone conversation passing through the subnetwork would be considered to be a new voice over IP microflow. Generally speaking, requests may be envisaged banning new microflows of a given type on a link, completely banning microflows of a given type on a link, deduplicating a type of microflow to be banned on the link on another link, or any request aimed at changing service quality.
The bandwidth controller 9 may inform the network manager 10 of the type of ban currently implemented on the link. The bandwidth controller 9 may, in particular, inform the network manager 10 that the link has been freed up. The network manager may then, for example, indicate to an operator that maintenance may be carried out on this link. The bandwidth controller 9 may also inform the network manager 10 of a planned time before the banning of the link becomes effective. The bandwidth controller 9 might also receive an end of link interruption instruction issuing from the network manager 10. The bandwidth controller 9 might then send commands re-establishing the microflow on the freed up link to the appropriate routing elements. The microflow may then be routed as initially by means of the re-established link. In this way, maintenance may be carried out in a way that is transparent for the user and for applications initially using this link.
If the bandwidth controller 9 determines that the microflow using a link to be interrupted cannot be rerouted, the bandwidth controller 9 might transmit, towards the network manager 10, or directly towards the terminals 2 or 3, an indication that this microflow will be interrupted without rerouting.
As a variant, the bandwidth controller 9 might send a general feedback message, towards the network manager 10, or directly towards terminals 2 or 3, including, for example, statistics relating to the microflows concerned, such as their number and percentage.
In addition, the bandwidth controller 9 may transmit an indication of the time before the suspending (here, the interruption) of the microflow's routing. The bandwidth controller 9 may also transmit an indication that a new flow may not be routed within the subnetwork 4, for example following this time period. If a terminal 2, 3 has itself requested a service quality, the controller may also transmit such indications to the terminal 2, 3.
The microflow traffic may therefore preferably be suspended with a time delay.
The routing of the microflow, which initially passed through the banned link, is carried out by any appropriate means. The network manager 10 may thus provide instructions for the distribution of the microflow between several other paths, in order to share out the load within the subnetwork. The bandwidth controller 9 may also change the routing of other microflows according to the microflow removed from the banned link.
The present variants and examples are given by way of illustration and are not restrictive. The invention is not deemed to be limited to the details provided here, but may be modified, while staying within the scope of the claims appended. Therefore, although a receiving and a transmitting terminal are described in the example, the invention of course applies to both directions in the microflow transfer process, or to terminals 2, 3, which are just intermediate elements in the transferring of microflows.
| Number | Date | Country | Kind |
|---|---|---|---|
| 04 50 301 | Feb 2004 | FR | national |
