High-Speed data network nodes are now implemented from a Tbps (Terabits per second) class of routers and switches which need to carry out an efficient flow-control so as to be lossless. Ideally, no packet should ever be discarded because a particular resource, generally a memory, is temporarily exhausted, while always permitting a full use of the available switching bandwidth. To achieve the necessary level of performance the switching functions are distributed between a switch core and peripheral devices including queuing devices, traffic managers and specialized network processors. Then, a flow control is performed between these devices which results in the need of having to exchange large amounts of information.
To reduce the amount of information, consuming a significant portion of the available communication bandwidth, to be exchanged between the devices participating in the flow-control a standard method is to only report the changes rather than the current status of the devices. For example, if an output switch port egress buffer never gets congested, just because it has not much traffic to handle, nothing is ever to be reported to the switch core. This frees the corresponding bandwidth for other needs.
Hence, this event-driven mode of operation is often preferred to a constant reporting of the current device status which translates, in the above example of the port egress buffer, into the fact that its filling level does not have to be permanently reported to the switch core while its occupancy stays low. In this event-driven mode of operation an event is e.g., the crossing of a filling watermark which must be reported, once, to the relevant devices.
However, this does not occur without introducing some problems. One of the problems created by this mode of operation occurs when one event reporting is missed by one of the devices. Since this information is only transmitted once if, for any reason, it is ignored or missed by the destination device, it cannot be normally acted on, a fact of which the originating device is not even informed. To remedy this, methods have been proposed assuming that an acknowledgment must be issued to each event by the destination device. As an example, U.S. Pat. No. 6,279,046 teaches how such a system can be carried out. This mode of operation requires, however, a level of management (issuing device must keep track of the forwarded event and make sure it receives the corresponding acknowledgment) which is not practically possible in a Tbps class of switches and routers where packets must be moved at a very fast rate i.e., below 10 Ns, when very fast switch ports are considered e.g., OC-768 at 40 Gbps nominal rate or OC-192 at 10 Gbps.
A second type of problem encountered when using an event-driven flow control is when a new device is turn on. Often, while a switch is up and running, a new port or part of port i.e., a sub-port (when several communications lines are sharing a same common switch port adapter) needs to be activated. Hence, the new participant has no knowledge of the status of the other components. The direct consequence is that it may attempt to immediately over-utilize the switching resources since it has no information that prevents it from not doing so. For example, the switch core may suddenly start receiving too much traffic from a new joining port adapter creating congestion and, may be, forcing it to discard packets possibly affecting other flows.