WO2001076159A1

WO2001076159A1 - Processing capacity management

Info

Publication number: WO2001076159A1
Application number: PCT/GB2001/001463
Authority: WO
Inventors: Robert Andrew Shipman
Original assignee: British Telecommunications Public Limited Company
Priority date: 2000-03-31
Filing date: 2001-03-30
Publication date: 2001-10-11
Also published as: GB0007834D0; AU2001242654A1

Abstract

In a communications network of nodes (110) connected by links (115), routing of traffic is done according to routine tables available to the nodes (110). The routing table for each node shows fields for services and for next hop nodes (205) towards those services, and traffic is routed at each node according to values entered in those fields. The nodes modify the values in the fields according to messages received from neighbouring nodes. This controls traffic flow in that values are raised on receipt of messages from neighbouring nodes. Where network nodes offer capacity such as storage or processing, it is available for data or processes to be routed to a node with higher available capacity, thus providing an element of load balancing. In this case, nodes with the capacity to carry out services 'advertise' this capacity by generating pulses, or short messages, at a rate determined by the available capacity at that node. Other nodes can then modify their routing tables to route traffic towards that node, or away from it if the inverse is the case.

Description

PROCESSING CAPACITY MANAGEMENT

The present invention relates to processing capacity management, particularly but not exclusively for use in packet-switched communications networks.

In distributed processing environments, it is becoming more common that more than one resource is available for carrying out a task. If the task is for instance data processing or storage, any of several different nodes in the network might be able to offer capacity to do that.

Embodiments of the present invention employ a simple form of messaging between nodes in a network for managing the routing of data or information or the like for processing or storage at a node with available capacity.

According to a first aspect of the present invention, there is provided routing control apparatus, for use in a node of a communications network comprising nodes connected to each other by links, the nodes being adapted to route traffic in the network in use,

wherein at least one of the nodes is a service access node at which access can be gained to at least one service over the network, which service access node is equipped to output service messages to other nodes of the network,

and wherein the nodes of the network are adapted to route traffic comprising service requests to selected neighbouring nodes in the network,

said routing control apparatus comprising neighbouring node selection means for use in routing received service requests towards a service access node, the neighbouring node selection means comprising:

i) a weighting factor store for storing weighting factors in respect of each neighbouring node; and

ii) weighting factor updating means for updating respective stored weighting factors in response to received service messages in accordance with the neighbouring node from which each service message is received. Embodiments of the present invention are suitable where data or software can for instance be adapted to identify a type of processing or storage capacity required, rather than a specific node location.

A network node in an embodiment of the present invention may be enabled to build a routing table from scratch in respect only of nodes it receives messages for and from.

A network management system according to an embodiment of the present invention is intended to be able to adapt to changing resource availability and equipment failure and to ease the task of expanding the network or adding new network services. It can do this by routing traffic towards nodes it gets incoming messages from and not routing traffic to nodes it gets few messages from, since these latter nodes are likely to be suffering from congestion or failure.

Each node may transmit traffic via a queuing mechanism. If outgoing routing-related messages are sent through the same queuing mechanism, this provides a fairly direct way of controlling traffic flow in the network since other nodes can adjust their routing tables so that they direct traffic away from nodes which are transmitting little or nothing.

According to a second aspect of the present invention, there is provided a method of routing service requests at a routing node in a network, the network comprising a plurality of nodes connected by links, at least one of which nodes is a service access node for providing access to a service over the network, the method comprising the steps of:

receiving at the routing node a service message from a neighbouring node, which service message has been output by a service access node;

storing a weighting factor, or updating a stored weighting factor, at or associated with the routing node, in respect of said neighbouring node; and

selecting a neighbouring node for routing one or more service request messages towards one or more service access nodes by reviewing all stored weighting factors in respect of neighbouring nodes at or associated with the routing node. According to a third aspect of the present invention, there is provided a method of indicating service capacity of a node in a network, which method comprises outputting from the node to the network messages at a rate determined by the service capacity of the node.

Other features and aspects of embodiments of the present invention are described below and indicated in the claims hereto.

A network management system is described below as an embodiment of the present invention, by way of example only, with reference to the accompanying drawings in which:

Figure 1 shows schematically a communications network, and a routing table of known type associated

with a node of the communications network;

Figure 2 shows schematically a weighted routing table according to an embodiment of the present invention associated with a node of the communications network of Figure 1 ;

Figure 3 shows steps in formation of a weighted routing table of the type shown in Figure 2;

Figure 4 shows pulse transmission by a node of the communications network of Figure 1 ; and

Figure 5 shows pulse content for a pulse transmitted by a node of the communications network of Figure 1 .

SYSTEM REQUIREMENTS

Pulsing Nodes, Weighted Routing and node availability

As shown in Figure 1 , a known network 105 can be represented generally as comprising nodes 1 1 0 connected by links 1 1 5. A routing table 100 is stored at each node. The routing table 100 gives a default "next hop", by listing the relevant next node against a given destination node, for each destination node in the network, typically calculated using shortest path algorithms.

Referring to Figure 2, services 210 may be provided from any of the nodes 1 10. As shown, node 1 provides service A, node 2 isn't shown as currently providing a service, node 3 is shown as providing service B, node 4 is shown as providing either of services A or C and node 5 is shown as providing service D.

In embodiments of the present invention, the network nodes 1 10 broadcast "pulses", or simple messages, to all neighbouring nodes. These pulses are used to generate weighted routing tables 200, as shown in Figure 2. In this case rather than give a "next hop" to a given destination node the routing table gives a "next hop" towards a given service.

The pulses are very lightweight, only containing information about the service it represents and when it was created, and are thus not likely to have a significant impact on the network bandwidth. Each service-providing node 1 10 in the network 105 advertises the presence of the services it provides by generating these pulses at a given frequency. The pulses propagate through the network and modify routing tables. Each pulse tends to modify the routing table so that data is encouraged towards its originating node 1 10 via the path the pulse has taken. The combination of pulses arriving at a node 1 10 thus together determine the path that data will take from that node to each other node in the network.

Looking at the routing table 200 shown in Figure 2, it can be seen that, rather than simply specify a definite next hop, each of the possible next hops 205 to get to a service 210 will be weighted in accordance with its perceived desirability, based on pulses received.

The rate at which pulses propagate through the network will affect the influence the pulses have on routing tables. If pulses are delayed, they will have less influence on a routing table than pulses which have travelled via a less congested route, simply because fewer of them are received within a given time frame and older pulses have a lesser effect on the weightings. If there is a problem in an area of a network, the pulses may actually be lost altogether. A convenient way of subjecting pulses to appropriate delay at each node is to put the pulse through a data, or message, queue at a node. If the node is already overloaded, the pulse will be appropriately delayed, or even lost, having the effect that routing tables in other nodes will tend to be less weighted to route traffic towards the overloaded node.

In preferred embodiments of the invention, the service-providing nodes may use variable frequency pulses. Referring to Figure 4, the frequency can then be dependent on conditions at the node 1 10 generating the pulses 405 for example current load in the data queue 400 or alternatively processing capability. Nodes may then advertise not only the presence of services but also their ability to perform those services. This may be important as networks become more active and are able to perform computational tasks for the user. The various nodes at which a given task can be performed would advertise themselves by pulsing at a frequency dependent on the node's current ability to carry out the task and nodes would be selected based on their frequency of pulsing.

Updating Routing Tables

The following describes how the routing tables 200 at the nodes 1 10 can be updated to weight the "next hops" for each service. The weights are adjusted in such a way as to increase the weight of the "next hop" to the node a pulse was received directly from (that is, a neighbouring node) when routing data towards a node that provides the service indicated by the pulse.

For the sake of simplicity, the following description covers the case where each of the nodes 1 , 3, 4 and 5 provides a single respective service. That is, the case where service A is not available from node 4.

Figure 2 shows a routing table 200 for a node 1 10 (Node 2) in which the next hop towards service C is already weighted towards neighbouring Node 3. This can be seen by the weighted values 0.65 and 0.35 assigned to neighbouring Nodes 3 and 1 respectively, against service C. If Node 2 now receives a pulse from Node 3 that was generated for service C, the weighting of Node 3 as a next hop for data for service C would be further increased in Node 2's routing table.

The weightings are always adjusted such that the total weightings for a given service sum to 1 . A formula for adjusting the weightings to be used is shown below. However, other formulae may be used, for instance that take into account previous updates and/or smooth out transients.

K,(t) l + δr max - min δr = h mm (3) age

Equation (1 ) specifies the new reinforced weight for the relevant service entered against a "next hop", when a pulse is received via that "next hop" for that service. Equation (2) specifies the amount by which the weights for that service entered against all other "next hops" are reduced. Equation (3) specifies an example reinforcement parameter that is used in Equations ( 1 ) and (2).

In the equations,

/ is the number of the current node 1 10 at which a pulse has been received s is the number of the service represented by the pulse, m is the number of the node the pulse was received,

/ indicates each neighbouring node (apart from the node the pulse was received from) for which the weight is to be reduced, and f and (t + 1) indicate time and time plus a discrete interval later.

The reinforcement parameter modifies the amount the weights are adjusted in Equations 1 and 2. It runs from a maximum value {max) to a minimum value (min). The precise value is determined by the age of the pulse such that young pulses with the minimum age of 1 result in a maximum value for the reinforcement value and old pulses produce a reinforcement value that tends towards the minimum value. Alternative reinforcement parameters are possible to modify the effect that pulses have on the routing tables. For example, an alternative to equation (3) may be devised in which the number of pulses already received from a node is taken into account. The reinforcement may be stronger for the first pulses received from a node so that, for example, weightings can be quickly adjusted when new services are advertised.

If now service A becomes available from node 4, nodes 1 and 4 will be "competing for business" with respect to traffic requiring service A. Again looking at what will happen at node 2, the most efficient route to service A from node 2 will become most heavily weighted in node 2's routing table. When service A is first available from node 4, node 4 starts to output pulses carrying the service A identifier. Node 2 will receive these pulses from both of its neighbouring nodes but it will receive them first via node 3 as node 3 is only a "two hop" route from node 4 to node 2 whereas node 1 lies on a "three hop" route from node 4 to node 2. Because pulses will have aged more going via node 1 , pulses coming via node 3 from node 4 will tend to increase the weighting of node 3 as a next hop from node 2 more than pulses coming via node 1 . However, in the long term node 2 will still route traffic for service A via node 1 because node^" 1 is a neighbouring node for node 2 and its pulses will be the youngest of all. In the short term, node 2 may temporarily route traffic for service A via node 3 because, as mentioned above, reinforcement may be stronger for the first pulses received from a node. If node 1 went out of service, or service A was suspended at node 1 , node 2 would adjust to sending traffic for service A via node 3 as this is the shortest route to node 4.

If a new network link were installed directly from node 4 to node 2, node 2's routing table would require a new column for node 4 as a next hop. Node 4's weighting would be favourable when first installed but, in the long term, the relative weighting against nodes 1 and 4 would depend on other factors, such as the nodes' relative capacity available to service A, as described above in relation to Figure 4.

Self-Configuration of Routing Tables

Referring to Figure 3, one of the requirements of the system is for it to be self- configuring. In order to achieve this, the routing tables are not pre-specified with entries for existing nodes and services 1 10 but will be formed entirely through the pulse activity. Routing entries for a given service and "next hop" nodes will only be formed when pulses are received that indicate such pairings to be possible. This "on-line" generation of routing information is shown in Figure 3 for the example of a network shown in Figure 2, with node 4 providing only service C. It demonstrates the formation of a routing table 200 for node 2.

Referring to Figure 3, in the initial state, the routing table 200 is completely empty with no knowledge of next nodes or services.

At time 1 , pulses are first received at node 2 which were actually generated by the neighbouring nodes to node 2. Hence the two nodes which are immediate neighbours of node 2 appear as both providers of services A and B and next nodes in the routing table for node 2. That is, as far as node 2 is concerned, a pulse has been received for service A "via" next node 1 and a pulse has been received for service B "via" next node 3. This means that weightings will be entered for next nodes 1 and 3 against the services A and B and the routing table 200 for node 2 now has knowledge of nodes 1 and 3 as next nodes and the presence of services A and B within the network. (Dashes in the routing table 200 indicate that no pulses have been received for the relevant next nodes against the services indicated.)

At time 2, pulses have now been received at node 2 for services C and D via next nodes 3 and 1 . Weights are therefore entered appropriately against the next nodes 3 and 1 and against services C and D All "next node" weightings at this stage show the value 1 . It should be noted that additional pulses have again been received for services A and B via next nodes 1 and 3. Since the "next node" weightings cannot go above 1 , these additional pulses have no effect there but they would otherwise reinforce the weightings for nodes 1 and 3 as "next hops" for services A and B respectively.

At time 3, pulses have been received for services C and D, but this time via next nodes 1 and 3 respectively. Thus the previous weightings against next nodes 3 and 1 respectively will be reduced and new entries made against nodes 1 and 3. The precise values for the adjusted weightings are dependent on the reinforcement parameter mentioned above. At time 4, additional pulses have been received for services A and B, this time via next nodes 3 and 1 respectively. This results in reduced weightings for next nodes 1 and 3 against services A and B, and newly introduced weightings for next nodes 3 and 1 against services A and B. Again, the actual values of the adjusted weightings are dependent on the reinforcement parameter. In this example, it can be seen that the adjustment made at time 4 is less than the adjustment made at time 3. In this case, there is a time dependent factor in the weight modification equations which means that pulses coming via a longer or more congested route, have less reinforcing effect on the weightings than pulses which have taken a shorter or less congested route.

It will be recognised that, in a more complex network, it would be likely that each node provides more than one service and that one service is provided by more than one node. The second situation is described above, where both nodes 1 and 4 provide service A. If one node provides more than service, it makes no difference to the way embodiments of the invention will build their routing tables as each service will have its own row in the routing tables of other nodes. Multiple services from one node are quite likely to generate different weightings at other nodes' routing tables as the weightings will be influenced by the capacity allocated to or used by instances of the respective services.

If one service is provided by different nodes in the network, it may be that at any particular node the service provided by both originating nodes reinforces the weighting for the same next hop. However, depending on where the originating nodes are situated in the network, there will be a node for which the next hops to each originating node are different. At this node, the weightings for the two (or more) next hops will be generated and/or adapted as described above.

Pulse handling and adaptation to changing traffic patterns Referring to Figure 4, when a pulse arrives at a node 1 10, the following procedure is followed:

1 . Pulses are immediately used to update the routing table as outlined above.

2. Each node 1 10 maintains a data queue 400 which holds data which needs to be either forwarded or processed by the node 1 10. Pulses which have been used to update the routing table 200 are then added to the same queue as the data. Their propagation is thus delayed by a period dependent on the load at that node 1 10.

3. On reaching the front of the data queue 400, the pulses 405 are broadcast to all neighbouring nodes with the exception of the node the pulse was received from.

The example demonstrated above with reference to Figure 3 did not consider delays at network nodes. However, in reality the arrival time of the pulses would be heavily dependent on the amount of congestion in the network. Pulses would arrive much less frequently via routes that were more congested and would thus increase the relevant weightings less than pulses arriving from less congested routes. The system is thus able to adapt to changing traffic conditions. If a previously good route became congested, pulses from other routes would update the routing table more frequently and encourage traffic away from the congestion. This adaptation would be occurring continuously, tracking the current conditions. It will be important to ensure, through suitable parameter selection, that the system does not track the traffic too closely, moving with every transient. There will be a playoff between adaptation and stability that will need to be considered.

The way in which the parameters are calculated can of course be tailored to the behaviour required in a particular network. In present embodiments a max of 0.2 and min of 0 have been used with success for the reinforcement parameter.

Adapting to Node Failure

A requirement of the system is for it to be able to quickly adapt to failures in the network. When a node 1 10 or link 1 1 5 fails, pulses 405 will no longer be generated or propagated in that part of the network. Thus, no weighting reinforcements will occur for routes involving the failed equipment. Pulses from elsewhere in the network would still be arriving however and, in the absence of the "competing" pulses would quickly modify the weightings to encourage data away from the failures. The speed at which these changes occur depends on the reinforcement parameter and the network congestion. Other mechanisms may also be used. For example if no pulses are received from a node in a given threshold period, the associated weighting may be automatically zeroed and re-distributed amongst the other possibilities. Taking the situation at "Time 4" shown in Figure 3, if no pulses were received from Node 3 in a given number of time steps, all weightings would be assigned to Node 1 making this the default node 1 10 for all traffic. When Node 3 was repaired and started again to transmit pulses 405, the routing table 200 would be modified as normal to reflect the changing situation.

Growing the Network and adding new Services

The system will need to accommodate new nodes 1 10 or links 1 15 placed in the network 105 and the provision of new services either at those new nodes or at existing nodes. This is supported by the self-configuration of routing tables 200 as described above. The only requirement is for the new nodes and services to be assigned a unique identification (ID). The service-providing nodes can begin transmitting pulses to advertise the presence of the services. These pulses would modify the routing tables 200 of other nodes 1 10 in exactly the same way as previously described. Pulses arriving from elsewhere in the network 105 would also be used to generate a routing table 200 with respect to a new node 1 10 or link 1 1 5.

Pulse termination and circular routes

The generated pulses 405 must be terminated at appropriate times to avoid swamping the network with pulses that are no longer required and maybe endlessly travelling around the network in circular routes. All pulses hold a timestamp indicating when they were created. After being used to update the routing table at a given node as described with reference to Figure 3 the pulses 405 are only placed into the data queue for onward transmission if a pulse for the same service and with the same timestamp has not already been handled by that node. Thus, pulses that arrive at a given node via a longer or more congested path are terminated as a pulse arriving by a shorter or less congested path has already been handled and advertised to other neighbouring nodes. This procedure eliminates the possibility of circular routes and reduces the number of pulses travelling around the network at any one time.

It would also be possible to operate a timeout so that pulses reaching a threshold age are discarded.

SYSTEM DESIGN A system according to an embodiment of the present invention can be developed using network simulation tools. The three main components of a pulsing nodes system are described below.

Pulses

The pulses generated by the nodes 1 10 are very simple and contain little information. The required information is encoded implicitly in the frequency of pulse arrival rather than encoded explicitly within a pulse. However, the pulses do need to store information regarding the service they were generated for and the time of their creation, which allows the age of the pulse to be calculated.

Referring to Figure 5, the initial pulse architecture comprises two sections: "Service" and "Time Stamp" .

The first section will need to be dimensioned according to the maximum number "N" of services expected in a network 105. The pulse 405 can be represented by an object in an object oriented system, which will provide methods for setting the source node variable and timestamp.

Routing Tables

In order to implement the self-configuring routing tables 200 required for the pulsing nodes system, a routing table class is required. An instance of this object will be contained in each node 1 10 in the network 105 and its job will be to hold the current routing information for that node. The algorithms for ascertaining how the tables are formed and how the weights are modified will be external to this class. It simply needs to provide a storage mechanism and methods to allow information to be added and modified.

The table needs to be two-dimensional and fully extensible. It can be implemented using a two-dimensional hashtable. The hashtable allows values to be associated with a key and efficient look-ups to be performed using that key. When pulses arrive for a new service a new entry will be created in the hashtable with the service ID as a key. The value associated with this key will be another hashtable with keys for each of the possible next nodes. The value associated with each of these keys will be the weighting. Information on hashtables and the like is available in the second edition of "Java in a Nutshell" by D Flanagan, for instance at page 545.

Network Nodes

The object implementing a major part of the system requirements will be the Node class. This class is responsible for maintaining a routing table 200, a data queue 400 and for handling and generating pulses 405. This class is preferably updatable. During its update there are three main procedures that need to be performed, these being as follows.

1 . Pulse Transmission. If the node 1 10 is a service-providing node, it will need to determine whether a pulse needs to be generated for each of the services and broadcast any generated pulses to neighbouring nodes. Initially, this will be at a fixed frequency so the node simply needs to keep a count, for instance of the number of update cycles it's been through, and generate a new pulse when the count reaches a given value. The node sets the pulse's "Service" Section 500 to be the services unique ID, and sets the "Time Stamp" Section 505 and transmits the pulse 405 to all neighbouring nodes. The update count is then cleared.

2. Handle Incoming Pulses. Before routing any data the node 1 10 must handle any incoming pulses as these are of a higher priority. For each pulse 405 that has arrived, the nodes routing table 200 is updated as described with reference to Figure 3. It then determines whether it has already handled a pulse with the same "Source" 500 and "Time Stamp" 505. If so, the pulse is discarded. Otherwise it is added to the same queue 400 as is used for the data.

3. Route the Data. The node 1 10 then needs to deal with the data in its data queue 400. It retrieves a number of entries from the queue; this number is a parameter that is dependent on the node's processing capability. The quicker the node, the more it can handle in one update cycle. It then checks whether the entries are pulses or packets of data. In the former case, the pulse 405 is broadcast to all nodes other than the one it was received from. In the latter case, the routing table 200 is consulted and the packet is sent to the "next hop" node 1 10, usually with the highest weighting. In the above, the primary purpose of the pulses is to modify routing tables at network nodes so that traffic carried by the network will tend to be routed towards the required services via the shortest or least congested route. Nodes output pulses at regular intervals and the pulse doesn't go through the data queue of the generating node. A number of nodes in a network may provide the same service and thus it would be desirable if a node was chosen both on the length and congestion of the path to that node and the node's ability to carry out the service.

In order to allow this, it would be useful if the frequency of pulse generation was dependent on the node's ability to carry out the service that the pulse represents. Thus, pulse generation frequency could be made dependent on for example the amount of storage currently available at a node or the current computational load experienced by the node depending on the service type. In this way nodes that are particularly suitable to carry out the service at a given time would generate pulses at a high frequency. Nodes that were less suitable would generate pulses at a lower frequency. More service requests would therefore be encouraged towards the nodes that were better able to perform the service. In some situations, it may also be desirable to place generated pulses into the data queue of the service-providing node so that the pulses are delayed at source when the load experienced by the node is high.

In the above, pulses contain timestamp data which is used to recognise a pulse previously received at a node. A pulse could also, or instead, contain hop count data. This would allow pulses which had travelled a long way in a network to be discarded. Pulses could still be individually identified, if required, by having a pulse identity.

It will be understood that it is not essential that the nodes themselves provide services in embodiments of the present invention but might in practice provide an access point to services which run on equipment elsewhere.

It is also not essential that there is more than one type of service as an embodiment of the present invention still offers advantages in routing traffic to a closest node which offers a service out of at least two nodes offering the same service, or alternatively to a node which has more or new capacity for offering a service. In this case, the content of a pulse could be the timestamp or hop count alone since only nodes offering access to the service would generate pulses and the pulses received by a node would still change the relative weighting for neighbouring nodes and thus have the effect that the receiving node routed traffic efficiently.

There are several ways in which a node can identify a neighbouring node from which a message is received. For instance, the message may be received at a particular port or over a particular channel dedicated to a particular neighbouring node, or communications from neighbouring nodes may carry identifiers for the respective neighbouring nodes specially for the purpose or for other purposes.

It is not essential that the weighting factor for a node from which a message is received is increased. It could be as effective just to decrease the weighting factor or factors associated with other nodes.

Claims

1 . Routing control apparatus, for use in a node of a communications network comprising nodes connected to each other by links, the nodes being adapted to route traffic in the network in use,

iii) a weighting factor store for storing weighting factors in respect of each neighbouring node; and

iv) weighting factor updating means for updating respective stored weighting factors in response to received service messages in accordance with the neighbouring node from which each service message is received .

2. Apparatus according to claim 1 wherein the updating means increases the respective weighting factor for a neighbouring node from which a service message is received.

3. Apparatus according to either one of the preceding claims 2 wherein the updating means decreases the weighting factor for each neighbouring node other than a neighbouring node from which a service message is received .

4. Apparatus according to any one of the preceding claims wherein more than one service type can be accessed by means of the service access node or nodes.

5. Apparatus according to claim 4 wherein each service message identifies a service type and the weighting factor store stores weighting factors for each neighbouring node for each service type.

6. Apparatus according to any one of the preceding claims wherein each service message comprises time data indicating a time associated with the creation of the message.

7. Apparatus according to claim 6 which further comprises a service message data store for storing said time data, and message discard means for discarding a received message if the time data for the message is already stored in the service message data store.

8. Apparatus according to claim 7 wherein each service message identifies a service type and the service message data store stores both time data and service type for a received service message, said message discard means being adapted to discard a received message if both the time data and the service type for the message are already stored in relation to one another in the service message data store.

9. Apparatus according to any one of the preceding claims wherein said weighting factor store is provided as a routing table.

10. Routing apparatus, comprising apparatus according to any one of the preceding claims, wherein the or each service access node is provided with service message output means which is adapted to output service messages at a rate in accordance with service capacity associated with said service access node.

1 1 . Routing apparatus, comprising apparatus according to any one of the preceding claims, wherein the or each service access node is provided with service message output means which is adapted to output service messages at a rate in accordance with current workload associated with said service access node in providing the or each service.

1 2. Routing apparatus, comprising apparatus according to any one of the preceding claims, wherein each node is provided with an event queue for queuing events requiring action by the node, traffic comprising service requests to be routed to selected neighbouring nodes being queued in said event queue.

1 3. A method of routing service requests at a routing node in a network, the network comprising a plurality of nodes connected by links, at least one of which nodes is a service access node for providing access to a service over the network, the method comprising the steps of:

selecting a neighbouring node for routing one or more service request messages towards one or more service access nodes by reviewing all stored weighting factors in respect of neighbouring nodes at or associated with the routing node.

14. A method of indicating service capacity of a node in a network, which method comprises outputting from the node to the network messages at a rate determined by the service capacity of the node.

1 5. A method according to claim 14 wherein each message, on output, comprises time data associated with its time of output.

1 6. A method according to either one of claims 14 or 1 5 wherein more than one service is available at or associated with nodes of the network and each message carries an identifier for a service provided at or associated with the outputting node.