In the field of communications packet-switched transport is widely used. Recently, IP-based transport solutions have received more attention. IP stands for Internet Protocol. The interest in IP is at least partially due to the flexibility and wide deployment of IP technologies. However, communication networks, such as telephone networks, have different characteristics when compared to traditional IP networks, because communication networks typically desire to be simple, inexpensive and to be able to provide a defined Quality of Service (QoS). Due to Quality of Service requirements, traffic congestion control is important in communication networks.
One of the concepts for providing QoS in IP networks is resource reservation in routers by signalling along the data path. As an example, the Internet Engineering Task Force (IETF) standardization organisation has specified a signalling protocol called RSVP (Resource ReSerVation Protocol) for making resource reservations in IP routers and for providing integrated services for real-time and nonreal-time traffic in the Internet (see e.g. R. Braden at al.: Resource Reservation Protocol (RSVP)—version 1 “Functional Specification”, RFC2205, September 1997; R. Braden at al.: “Integrated Services in the Internet Architecture: an Overview”, RFC1633, 1994; J. Roclawski: “The Use of RSVP with IETF Integrated Services”, RFC2210, September 1997). In this technology, RSVP signalling messages reserve resources in each router along the data path before sending a real-time traffic flow. Real-time flows are admitted into the network if resources are successfully reserved in each router along the data path.
This method requires storing per-flow reservation states in each router along the data path. The reservation states are soft states, which means that they have to be refreshed by sending periodic refresh messages. If a reserved state is not refreshed, the state and corresponding resources are removed after a time-out period. Reservations can also be removed by explicit tear-down messages. With the help of per-flow states, RSVP messages always follow the data path up- and downstream. Therefore, it is able to inter-work with standard routing protocols. If the traffic is re-routed, e.g. due to overload of a router, refresh messages make reservations in the new data path. Storing per-flow states in each router also enables the possibility of local path repair. After re-routing, if there are not enough resources to support all flows desired for the new path, some flows can be terminated.
Storing and maintaining per-flow states in each router can be a problem in large networks, where the number of flows and therefore the number of reservation states can be high. In response to this scalability problem of RSVP, the IETF specified an RSVP aggregation method that allows making reservations for aggregated flows (see RFC3175, September 2001). Aggregated reservation states are not necessarily created, modified or refreshed for each flow request.
The RSVP method of aggregation is capable of making an admission control decision only at an aggregated level, which means that all flows that are treated together as an aggregate are terminated if there are not enough resources on a new path after re-routing.
As means for providing QoS in large-scale networks, an architecture referred to as Differentiated Services (DiffServ) was proposed, see RFC2475, 1998. In the DiffServ architecture scalability is achieved by offering services on an aggregate rather than per-flow basis, and by arranging the system such that as much as possible of the per-flow state information is kept at edge nodes of the network, and only aggregated state information is kept in the interior nodes. The service differentiation is achieved by using a specific field in the IP header, the so-called Differentiated Services (DS) field. Packets are classified into Per-Hop Behaviour (PHB) groups at the DiffServ edge nodes. Packets are handled in DiffServ routers according to the PHB indicated in the DS field of the message header. The DiffServ architecture does not specify any way for devices outside of the domain to dynamically reserve resources or receive indications of network resource availability. In practise, service providers rely on subscription-time Service Level Agreements (SLAs) that statically define the parameters of the traffic that will be accepted from a customer.
DiffServ networks provide QoS for real-time traffic in a scalable way. DiffServ is a static architecture in which traffic is limited at the domain edges, and interior nodes have to be designed with proper dimensioning. There are no dynamic mechanisms for dealing with overload due to re-routing within the domain, such that interior nodes and links need to be over-dimensioned with respect to average load, in order to provide a QoS guarantee up to at least a certain level.
The IETF Next Steps In Signalling (NSIS) working group is working on a protocol to cope with new signalling requirements in IP networks, see RFC3726, April 2004. The QoS signalling application protocol of NSIS is similar to RSVP, but it has some additional features, such as supporting different QoS models. One of the QoS models is Resource Management in DiffServ (RMD). RMD defines scalable admission control methods for DiffServ networks. It also includes a congestion control function that is able to terminate a number of flows in a congestion situation, in order to maintain a required QoS for the rest of the flows.
An important characteristic of IP networks and some other packet switched networks compared with other technologies used in communications, such as ATM or SDH, is that IP routing protocols automatically adapt to topology changes for example, if a link or node fails, traffic is automatically re-routed. However, a problem can occur in that the new path may not be able to support all of the re-routed flows, e.g. due to a lack of bandwidth. In such a situation congestion management is desirable.
RMD defines functions for notifying edge nodes of a DiffServ domain about congestion occurring in interior routers. These notifications are based on “remarking” of data packets in the DS field in the interior routers in proportion to the overload. An edge note can then measure the number of marked packets and send a termination message for some flows, if it is necessary to reduce the traffic load.
An algorithm for reacting to congestion is e.g. described in Andràs Csàszàr, Attila Takàcs, Robert Szabo, Vlora Rexhepi and Georgios Karagiannis “Severe Congestion Handling with Resource Management in DiffServ on Demand”, in proceedings of Networking 2002—The Second International IFIP-TC6 Networking Conference, vol. 2345 of INCS, pages 443-454, 2002, Pisa, Italy, or in Lars Westberg, Andràs Csàszàr, Georgis Karagiannis, Adam Marquetant, David Partain, Octavian Pop, Vlora Rexhepi, Robert Szabo and Attila Takàcs “Resource Management in DiffServ (RMD): A Functionality and Performance Behaviour Overview” in proceedings of PfHSN 2002—7th International Workshop on Protocols for High-Speed Networks, vol. 2334 of INCS, pages 17-34, 2002, Berlin, Germany.
A problem encountered in such algorithms can be that of over-reaction to a congestion condition by terminating more flows than necessary to decrease congestion. This is also called under-shoot, in that the actual load falls below a desired level due to the over-reaction.
WO 2206/052174 describes ways of dealing with the problem of over-reaction. In the described system, the interior routers of a domain mark packets in proportion to the overload, and the signalled overload is stored. In other words, the interior routers or nodes have a form of “memory” for measured overload. This memorized information is then taken into account when marking new packets in the future. Furthermore, the interior routers mark the forwarded data units proportionally to the degree of overload, and the egress nodes count the marked data units, in order to measure the degree of overload.
USPTO Backgrounds
USPTO Backgrounds