Method and apparatus for distant congestion control of meshed streams in a packet-switched telecommunications network

ES 2 333 748 T3

DESCRIPTION

Procedure and device for remote control of mesh flow congestion in a telecommunication network in packet mode.

Technical field

The invention is situated in the field of telecommunications and relates more specifically to a procedure for remote control of the congestion of mesh flows exchanged in a packet mode telecommunication network between a number N of central sites C, provided with communication equipment. flow management and a number M of remote sites D_m they do not understand such teams.

The invention also relates to a device intended to put this method into practice.

The invention applies regardless of the geographical extension of the network, the data transmission speed sent by it and the number of users of this network. In particular, it works in the case where users from the same remote site D_m they communicate simultaneously with several central sites C,, thus forming mesh flows.

The invention is independent of packet mode network technologies, but it is particularly adapted to networks that use the IP protocol (Internet Protocol), such as, for example, the Internet network or VPN networks (Virtual Private Networks or Virtual Private Networks). The latter offer an interconnection at the IP level exclusively for a given group of users (usually a company or organization with several establishments), while using a shared network infrastructure (for example, the Internet).

Prior state of the art

Telecommunication networks in packet mode are characterized in that the information sent is transmitted in groups called packets, essentially made up of a header that contains the information for sending the packet in the network and the data to be transmitted. The addressing information contained in the headers makes it possible to identify information flows between the end applications. These packets are transmitted through the network and take, at the convenience of this network, a wide variety of transmission and switching media. The technology mainly used today for these packet mode telecommunication networks is the IP protocol (Internet Protocol). This protocol is used end-to-end and can be transmitted over many different transmission networks, such as Ethernet networks, FR (Frame Relay) networks, ATM (Asynchronous Transfer Mode) networks, SDH (Synchronous Digital Hierarchy) networks, SONET networks. (Synchronous Optical Network), MPLS (Multiprotocol Label Switching) networks or even DWDM (Dense Wavelength Digital Multiplexing) networks, etc.

Classically the packets are emitted by a great number of sources that work independently of each other, towards a great number of destinations that also work independently of each other.

Figure 1 shows an example of a network like this:

Users 2 can be individual users, agencies, companies (which have their own internal local network), etc.

The transit network 4 represents the central part, generally of great capacity and covering a large territory (the entire world in the case of the Internet network). This network is generally shared by a multitude of users and / or private networks.

The access networks 6 generally have a medium or slow data flow and are shared by users located in a limited geographical area. The "local loop", cable, optical, radio link, etc., between the user and the access service provider is therefore considered to be part of the access network.

Quality of service

The Quality of Service is constituted by the set of pertinent characteristics that affect the transfer of information between two given points of a network. It is defined especially by:

- the quality of access to the service;

- the availability of the service;

- the time of re-establishment of the service in case of failure;

- the quality of the information transfer service;

- the information transfer time elapsed between origin and destination;

- the variation of the elapsed information transfer time (instability);

ES 2 333 748 T3

- the degradation of the transmitted information (losses, errors);

- the amount of information that can be effectively transmitted over the network (bandwidth).

The geographical extension, the great common use of infrastructure equipment among many users, the variety of exchanged flows and the complexity of the deployed architectures make it very difficult to predict and guarantee the Quality of Service in such networks.

The data transmission speed that can be transmitted between two given users, the elapsed information transfer time, the variation in time of this elapsed time (instability) and the associated loss rate are fundamental elements of this Quality of Service. . Its control is the only thing that allows the deployment of critical professional services (transport of voice, images, transactions, critical data, electronic commerce, etc.).

A normal way to improve the quality of service is to increase the capacity of the network. However, given the high investment and use cost of these networks, it is desired to use them to the maximum and therefore a very expensive solution such as this has limited use.

Devices (protocols, transmission, switching, routing equipment, etc.), depending on the nature of the different networks, can be put into practice to manage these elements of Quality of Service. They are generally based on priority and resource reservation mechanisms for the request (AATM, RSVP over IP ...) or for the configuration (ATM, DiffServ over IP ...). These devices generally have a limited range only to a part of the network. Being in constant mutation, they interact with difficulty.

In all cases, the result depends largely on the behavior of the origin users: transmission data transmission speed, traffic regularity, traffic matrix, etc. This behavior is very difficult to predict, due to the great variety of the applications used by the networks (voice and image transport, file transfer, database consultation, etc.), of the multiplicity of users present and the great variety of their needs.

Also in all cases the result depends to a great extent on the engineering rules and the configuration of the multiple parameters of the network. These rules are very difficult to determine, in particular due to the size of the networks, the great variety of technologies used at a given moment (non-homogeneous fleet) and the multiplicity of organizations (service access operators, network operators). points of presence, long-distance transporters, etc.) involved from the beginning to the end of the road.

The phenomenon of network congestion

Congestion is defined as a state in which the use of the resource reaches the maximum capacity that this resource is capable of providing. In the case of networks, it is essentially about bandwidth: a junction or a junction element becomes congested when the information data transmission speed approaches, reaches and even tries to exceed the maximum data transmission speed that this junction or this junction element is capable of transmitting without degradation (loss of information, delay ...).

The Quality of the Service is mainly related to the congestion of the different elements of the network taken by the information during its transfer. Although there are an infinity of gradations, an outline of the operating cases faced by these two modes can be made:

- Either there is no allocation of resources and the network does its best to get the information to the recipient, depending on the activity of the origins;

- Either there is a resource allocation mechanism and the amount of information injected into the network by each source is more or less controlled.

In all cases, temporary queue storage systems (memories), located at each multiplexing, concentration or switching point, make it possible to handle packet arrival simultaneities. The instantaneous memory occupation rate that a packet finds and the management policy (priority, number of queues, emptying rule, rejection ...) implemented at the level of each queue determine the time that a packet has spent in this device, as well as its eventual rejection.

The transfer time between two points on the network is due to:

- to the sum of the times of crossing the lines, cables, optical fibers, satellite links, etc., used; this elapsed time is generally fixed and depends essentially on the media and the distance traveled by the information,

- to the sum of the times of crossing the queues in the different teams; this elapsed time is globally due to the instantaneous load encountered by each packet and to the management policies of these queues.

ES 2 333 748 T3

Furthermore, an instantaneous load that is too large causes a rejection of the information packet (loss); This phenomenon is the one that mainly explains the loss of packets.

It is seen, therefore, that the phenomenon of congestion implies great unpredictability in exchanges between origins and destinations, thus preventing any guarantee of proper functioning for the users of said networks.

Congestion management issues in a mesh environment

A mesh situation is defined when, at any given time, several independent source sites broadcast traffic to the same destination site or even when the same source site broadcasts traffic to several destination sites or any combination of these two cases.

Traditional congestion treatment management

The solutions known in the prior art to allocate the resources and particularly the bandwidth in a point-to-point environment use either the priority mechanism, implemented in each element of the network (router), based, or on the definition class of service (Diffserv), or the traffic shaping mechanism (Traffic shaping) from a central site to one or more destinations. The conformation criteria can be more or less static and more or less fine depending on the implementations. Documents WO2004066567 ("Limitation of traffic in packet-oriented networks with the help of limit values ​​depending on the junctions for traffic passing the limits of the network") and WO0180485 ("Method of optimization of a network") describe known examples in this sense.

These solutions do not directly take into account the meshes of the flows. They are complemented by static engineering and sizing rules. The results in the presence of meshes are very approximate and the lack of control that is inherent to them does not provide a guarantee of good operation.

A solution is also known that allows taking into account mesh flow type situations, coordinating in real time the decisions made by the equipment installed in the different origin and destination sites. A solution like this is described in the French patent application "Procedure for Dynamic Optimization of Service Quality in a Data Transmission Network" No. FR 2,804,808 filed by the applicant.

This solution makes it possible in particular to rediscover a predictability of returns. However, it needs to equip all the sites, which can be shown to be complex and / or expensive, particularly in the case where a small number of central sites (typically international, national or regional headquarters and data centers (data centers) exchange information with a large number of remote sites users of data transmitted by these central sites (classically agencies), each of these remote sites being related to one or more central sites.

The object of the invention is to alleviate the drawbacks of the prior art described above.

Presentation of the invention

The invention recommends a method of remote control of the congestion of mesh flows exchanged in a telecommunication network in packet mode between a number N of central sites C, provided with active flow management equipment and a number M of remote sites D_m Without such equipment, said central sites exchange information specifically destined to the management of the flows exchanged between each of the central sites and each of the remote sites.

The process according to the invention comprises the following steps:

- dynamically associate each remote site to a subset of central sites based on the traffic actually tested,

- establish a dynamic traffic matrix indicating, for each remote site, the group of central sites that exchange data with this remote site during a given observation period,

- exchange between the different central sites of each group minimum information on the traffic in real time with each of said remote sites,

- define from the information exchanged in the previous stage a local image that indicates the pre-congestion status for the traffic of each remote site (14),

- calculate traffic management rules from (respectively to) each remote site based on the image defined in the previous step.

ES 2 333 748 T3

Preferably, the flow management comprises the following preliminary stages:

- automatically configure the active teams of the central sites based on these dynamic groupings,

- For each remote site, coordinate the active teams of the central sites in such a way that traffic to the destination or from the same central sites to / from this remote site is managed in real time.

According to a preferred mode of implementation, the process according to the invention comprises the following steps:

In this embodiment, for each remote site and for each data exchange session from (respectively to) this remote site, the calculation of the traffic management rules is executed locally at each central site and comprises the following steps:

- detect pre-congestion close to the maximum exchange capacity of (respectively towards) this site,

- distribute the transmission resources among the different data exchange sessions as a function of the pre-congestion states detected, the nature and the number of these sessions.

In a preferred embodiment variant, the execution of the stage of establishing a dynamic traffic matrix is ​​distributed among the active flow management equipment of the different central sites so that each central site C_k:

- determine a list of remote sites D_m with whom you have exchanged information during the observation period,

- periodically exchange this list with the rest of the central sites,

- constitutes a base (M_im) of information that is the matrix in the set of central sites C, and remote sites Dm,

- deduce, for each remote site n, the central sites (C_kn) with which the remote site has exchanged information during the considered observation.

In this variant embodiment, the establishment of a dynamic traffic matrix is ​​periodically executed during a first processing loop that has a duration adapted to establish an associated traffic matrix, taking into account the overlap of all types of traffic during said period. , the exchanges of information between the central sites and the definition of a local image indicating the pre-congestion state are executed periodically during a second treatment loop, which has a short duration with respect to the first treatment loop, and it is adapted to establish a matrix of the real-time traffic so that the different congestion states are detected in real time and the calculation of the traffic management rules is executed periodically during a third processing loop that has a very short duration with respect to the execution durations of the first and second treatment loop so that the traffic is regulated in real time according to the type and quantity of flows exchanged between the central sites and remote sites.

In another alternative embodiment, the execution of steps a) is managed by a central management team as follows:

- each active device at each central site performs an activity measurement for the traffic between it and each remote site, for the two communication directions,

- the centralized management team periodically collects traffic information on all active computers at each central site,

- the centralized management team derives from this for each remote site the list of central sites with which it exchanges information,

- the centralized management team communicates these lists to the active team at each central site.

The method according to the invention is particularly (but not exclusively) adapted to private networks (virtual or not), made up of a large number M of remote sites (classically several hundred to several thousand) and a more limited number N of central sites (typically a few dozen) (headquarters and data centers): banks, insurance companies, car rental networks, large distribution, large industrial companies.

The invention also relates to a remote control device for the congestion of mesh flows exchanged in a telecommunication network in packet mode between a number N of central sites Ci provided with flow management equipment and a number M of remote sites Dm devoid of such equipment, the number N of central sites Ci being small with respect to the number M of remote sites Dm.

ES 2 333 748 T3

The device according to the invention comprises:

- means for establishing a traffic matrix indicating, for each remote site, the group of central sites that exchange data with this remote site during a given observation period,

- means for exchanging between the different central sites of each group minimal information on the traffic in real time with each of said remote sites,

- means for defining from the information exchanged a local image that indicates the state of congestion at the level of each remote site,

- means for calculating and applying traffic management rules from (respectively to) each remote site based on the defined image.

Said means for establishing a traffic matrix are arranged either at each central site or at a central management team.

Brief description of the drawings

Other characteristics and advantages of the invention will emerge from the description that follows, taken by way of non-limiting example, with reference to the attached figures in which:

figure 1 schematically represents a general structure of a telecommunication network, figure 2 schematically represents a network architecture model in which the method according to the invention is put into practice, figure 3 represents a network according to the model of figure 2, comprising central sites and remote sites that implement the method according to the invention, Figure 4 schematically represents data flows exchanged between two central sites and three remote sites in the network of Figure 3, Figure 5 represents the essential steps of the method according to the invention, Figure 6 represents a traffic matrix obtained by the method according to the invention, figure 7 schematically illustrates the constitution, according to the invention, of groups of central sites from the traffic matrix of figure 6.

Figure 8 is a block diagram illustrating the stages of building a local image of the activity of a remote site according to the invention, Figure 9 is a block diagram illustrating the stages of calculating the bandwidth by sites exchanges according to the invention, figure 10 illustrates the detection, according to the invention, of a potential congestion point in the network of figure 4, Figure 11 schematically illustrates the chaining of traffic conditioning seen from a central site according to the invention.

Detailed exposition of particular embodiments

The description that follows refers to an application of the procedure in a context represented by figure 2 that illustrates the case in which a reduced number of central sites 12 such as international, national or regional headquarters and data centers (data centers) exchange information with a large number of remote user sites 14 such as agencies, each of these remote sites 14 being related to a subset of central sites 12.

In this type of architecture, there are two important needs that must be satisfied simultaneously:

- control the performance perceived by the users of the remote sites 14, despite the complexity generated by the meshes of the flows (simultaneous communications from / to several central sites);

- limit the number of active teams in charge of traffic management, so that it is simplified and a deployment is obtained with a reduced cost.

ES 2 333 748 T3

Figure 3 represents an interconnection network 10, using the IP protocol for example, that interconnects a set of two central sites (C,) 12 with a set of three remote sites (D_m) 14. The technology (s) used in this interconnection network are any, for example: MPLS, Frame Relay, AtM, ADSL ...

Each central site 12 classically comprises one or more application servers 16 and one or more databases 18 common to several users. The central sites 12 can also comprise user workstations 19. All these elements are connected to a local network hub or switch 20. An interconnection network access equipment 22, generally called CPE (from Customer Premises Equipment ) secures the interface between network 10 and central sites 12.

Each of the central sites 12 is provided with active equipment 30 intended to remotely control the remote sites 14.

Each remote site 14 conventionally comprises user workstations 19, but optionally also one or more application servers 16 and one or more databases 18 for the users of the site. All these elements are classically connected to a local network hub or switch 20. An interconnection network access equipment (CPE) 22 ensures the interface between the network 10 and the remote site 14.

Traffic between sites

For the implementation of the method according to the invention, it is assumed that the main traffic through the network 10 is constituted by one-way or two-way exchanges between the central sites 12 and the remote sites 14. Assuming that the latter are devoid of active equipment .

Traffic in network 10 is schematically illustrated by arrows 32 in Figure 4.

In particular:

- a remote site 14 can exchange a flow simultaneously with several central sites 12,

- a central site 12 can exchange a stream simultaneously with several remote sites 14,

- the central sites 12 can exchange a stream simultaneously with each other,

- the remote sites 14 do not exchange a flow between them.

It is also considered that the traffic between the different central sites 12 and the remote sites 14 is dynamic, that is, it changes rapidly at the same time in space (change of the sites that exchange between them), in volume (change of the amount of information to be exchanged) and its nature (change in the type of information that is exchanged).

Control system

Each active equipment 30 is installed in such a way that:

- there is knowledge of the traffic between the central site 12 where it is installed and the remote sites 14;

- there is knowledge of the eventual traffic to / from the other central sites 12;

- it can communicate with the other active equipment, for example, but not necessarily through the network 10;

- the user traffic of the central site 12 can be intercepted so that it is reorganized if necessary.

These 30 active teams are classically constituted by:

- a central unit and the dead and live memory necessary for the execution of the software;

- network interfaces to capture and re-inject user traffic;

- network interfaces to communicate with each other (these can be the same interfaces as the user traffic capture and re-injection interfaces);

- an integrated software that allows to communicate, execute calculation algorithms, make decisions and apply them.

In a first variant of embodiment, the active devices act with each other without resorting to a central device.

In a second variant embodiment, the active equipment interacts with a central software connected at any point in the network 10 and with which they can exchange information.

ES 2 333 748 T3

Principles of remote control of mesh flows

In a preferred embodiment, the process according to the invention comprises the following steps:

- dynamically associate each remote site 14 to a subset of the central sites 12 based on the traffic actually checked,

- automatically configure the active teams 30 of the central sites 12 based on these dynamic regroups,

- Coordinate the active teams of the central sites 12 in such a way that traffic to or from the remote sites 14 is managed in real time.

The remote control of mesh flows is then carried out by all the active teams that collaborate in real time.

Figure 5 illustrates the steps of a particular example of putting the method according to the invention into practice.

These stages consist of:

- determine the traffic matrix between the central sites 12 and the remote sites 14 in the medium / long term (step 50),

- establish (step 52) Remote Coordination Groups 40 (see Figures 3 and 4) (RCG: Remote Coordination Group) that comprise the identity of the remote site 14 that must be controlled from the central sites 12, the list of the central sites 12 with this remote site 14 and which must therefore be coordinated to ensure the best allocation of resources,

- exchanging information on traffic in real time between the active equipment 30 of the central sites 12 of the same group 40 (step 54),

- constituting in each active equipment 30 the local image of the traffic of each remote site 14 (step 56),

- determine the traffic management rules for the active equipment 30 of the central sites 12 (step 58),

- conditioning the traffic entering and leaving the active equipment 30 of the central sites 12 (step 60).

The steps described above are executed in three loops, a first medium / long term management loop 62, a second short term management loop 64 and a third very short term control loop 66. The association of these three closed-loop processes, combined with the behavior of the network and the applications, is what ensures the proper functioning of the whole and allows the control of mesh traffic.

Determination of the traffic matrix in the medium / long term (stage 50)

This step 50 consists of determining, for each remote site 14, the central sites 12 with which said remote site 14 exchanges data.

It is essentially a matter of observing the traffic coming and going to each remote site 14 and classifying it according to the central site (s) 12.

We note that in most real-world situations, this observation can be made over a fairly long period of time (for example, a day or a week). In effect, the associated traffic matrix is ​​searched, that is, the matrix that reflects the superposition of all traffic in the period considered.

The determination of this traffic matrix can be carried out centrally or decentrally.

In the centralized variant:

- each active device 30 at each central site 12 performs an activity measurement for traffic between itself and each remote site 14, for the two communication directions,

- a centralized management team periodically collects traffic information on all active computers at each central site 12,

- this centralized management team derives from it for each remote site 14 the list of central sites 12 with which it exchanges information,

- the centralized management team communicates said lists to the active team 30 of each central site 12.

ES 2 333 748 T3

After classification and association, the central management team is then able to determine the traffic matrix that refers to each remote site 14. This matrix indicates the list of central sites 12 with which the remote site 14 has exchanged information. during the period considered.

The centralized variant is well suited for cases where the traffic matrix is ​​stable, that is, it varies little over time, which is the more general case insofar as the central sites 12 are often well identified and they undergo few modifications.

In the decentralized variant, the central sites C, 12 are those that carry out the treatments described above:

Each active team 30 from central site C, 12:

- determines the list of m (where m is an integer) remote sites D_m 14 with whom you have exchanged information in the observation period considered for both directions of communication,

- periodically exchange this site list with all other active teams 30 from central sites 12, and

- constitutes an information base that is the matrix in the set of the N central sites 12 and the M remote sites 14: {M_nm},

- deduce, for each remote site n among the M sites, the central sites k involved (M_kn).

The decentralized variant has the advantage of a fully distributed mechanism, which does not require a central function, but nevertheless requires additional signaling flows between the central sites 12.

In the probable case of a slow evolution of the correspondences between central sites C, and remote sites Dm, the period Ti of emission of these flows can be kept at a very low level (for example, an information exchange every hour between the central sites 12), which will not present a significant additional load on the network 10.

Figure 6 illustrates an example of a traffic matrix obtained by means of the method according to the invention.

This matrix comprises a line containing all remote sites 14 and a column containing all central sites 12. The intersections of each line and each column contain a “1” if these sites exchange data and a “0” if they are not. So.

Constitution of Remote Coordination Groups 40 (stage 52)

An RCG 40 Remote Coordination Group (for Remote Coordination Group) is made up of:

- the identity of the remote site 14 to be controlled from the central sites 12,

- the list of central sites 12 that regularly have traffic with this remote site 14 and that must therefore be coordinated to ensure the best allocation of resources.

Figure 7 schematically illustrates the constitution of a medium-term traffic matrix as well as the corresponding RCGs.

We observe that the RCG 40 can be directly derived from the traffic matrix by the active equipment (see Figure 6). They evolve at the speed of this matrix (in the medium / long term) and their constitution does not create a significant internal treatment load to the system.

We also note that inter-site traffic 12 does not return to the notification line at this stage, as it is assumed here to be handled by “classical” inter-site traffic control mechanisms.

Exchange of information on traffic in real time between the active teams of the central sites 12 (step 54)

This stage is carried out by each of the active teams of the central sites 12, for each RCG 40 to which they belong.

It takes into account the real-time aspects of the traffic which refers to the instantaneous traffic matrix, the nature of this traffic and the number of active users.

An obligation at this stage is to find the best possible balance between the following two obligations:

- exchange flows as quickly as necessary in order, on the one hand, to be able to detect the different states of congestion and, on the other hand, to regulate the flows according to their nature and importance;

ES 2 333 748 T3

- Exchanging as little information as possible to limit the load on the network and thus guarantee the evolution (increase) of the size of the system and allow to reach very large deployments.

In the continuation of the description, the traffic will be classified into "Classes" that are defined according to the nature and importance, especially economic, of the applications. This classification depends of course on the activity and applications of each organization. For instance:

- Class 1: voice traffic - critical,

- Class 2: video traffic - critical medium level,

- Class 3: critical transactional traffic,

- Class 4: non-critical transactional traffic,

- Class 5: Internet traffic - critical of medium level,

- Class 6: file transfer - low level critical.

A "Session" is defined as the association of a user station and a server (or another user station or between two servers ...) through the network 10 and that exchange information to execute a given application (conversation telephone, data transfer, access to a website ...). The location and / or identity of the job and / or the server and / or the application allows the session to correspond to its class. We also note that there can be many different sessions between two same sites. Furthermore, the same user station can be simultaneously involved in several sessions.

Nature of exchanges

Let remote coordination group RCGm be relative to remote site m. The exchanges have at least two objects: the detection of congestion and the final regulation of the flows.

• Detection of congestion:

Each active central site team C¡ member of this group RCG_m periodically issues to the other active teams in the group's central sites at least the following information:

• TC¡D_m: data flow emitted by the central site i towards the remote site m (bit / s), • TD_mC¡: data flow received by the central site i from the remote site m (bit / s).

• Fine regulation of flows:

Each active team at the central site C¡ member of the group also broadcasts the following information to the other active teams at the central sites of the group:

• S_kCD_m: number of active sessions of class k from central site i to remote site m, • S_kD_mC ,: number of active sessions of class k from remote site m to central site i.

The period T₃ The emission of this information must be relatively short, since it must allow to follow the evolution of the traffic in real time. In current networks, a period of about one to several seconds can be considered desirable.

Quantification of exchanges

Suppose a remote site Dm such that, at a given time:

- is active from / to C central sites C¡ simultaneously (members of the RCG_m);

- the sessions are bidirectional from / to each of the central sites C,;

- have K classes of active traffic from / to each of the central sites C,;

- each TCD and TDC information has a length of L_t bytes;

- each SCD and SDC information has a length of L_s bytes;

ES 2 333 748 T3

For the control of the RCG_m, each active team of central site C, involved will have to generate with a period T₃ a message (or a set of messages) to each of the (C-1) other central sites, the total length of which is:

Data flow for each direction + number of active sessions for each class and for each direction = 2 * (L_t + K, * L_s)

In total, the central site C therefore emits [1 / T₃ * (C-1) * 2 * (L_t + K, * L_s) * 8] bits / second of messages involving remote site Dm.

Example of digital application:

T3 = 1 second

C = 4 central sites members of the RCG

K, = 4 active traffic classes between D_m and C¡.

Lt = 2 bytes

Ls = 2 bytes

Total data flow of messages from C, = 1 * 3 * 2 * (2 + 4 * 2) * 8 = 480 bit / s

It is observed that this value is particularly modest with respect to the data flows usually available at central sites (currently several Mbit / s to several Gbit / s).

Constitution of traffic images (stage 56)

Local image of local activity

Each active host 30 of central site 12 constitutes an image of its own activity for the data flows to / from all remote sites 14 and the rest of central sites 12.

This stage does not need any information exchange with other teams.

Let C, be a central site, this site will build the IL image of your local activity that is made up of at least:

• Tegi: Total data transmission speed from the interconnection network 10 to the central site C ,, • Tig ,: Total data transmission rate from the central site C, to the interconnection network 10, • Seg_{k; i;} i: Total number of active sessions for each class k of traffic and that goes from the interconnection network 10 to the site Ci, • Sig_{k: i:} i: Total number of active sessions for each class k of traffic and coming from site C, towards the interconnection network 10.

When numbering traffic classes k from 1 to k_max, is obtained:

ILi = {Teg ,; Tig ,; Sec_or; Sec₂.i; ... Seg ^ or Sig_or: Sig ^; ... Sig ^.,}

Local image of remote activity

At this stage, each active central site team 30 12 will reconstitute an image of the global activity of each remote site 14 for which it is a member of RCG 40. This image takes into account the activity of the remote site data streams. 14 from / to all central sites 12.

It is important to note that at this stage, there is no exchange with the other members of RCG 40 and that the information exchanged in stage 54 is used regularly.

ES 2 333 748 T3

Let be the central site Ci, belonging to the RCGm of the remote site Dm. The Ci site will build the IDim image of the activity of the remote site Dm, which is made up of at least:

• Teg_m: Data transmission rate from interconnection network 10 to remote site D_m, • Tig_m: Data transmission speed coming from remote site D_m towards the interconnection network, • Seg_k,_m: Number of active sessions for each class k of traffic that goes from the interconnection network 10 to the site Dm, • Sig_k,_m: Number of active sessions for each class k of traffic coming from site D_m towards the interconnection network 10.

When numbering traffic classes k from 1 to K_max, is obtained:

^IDim = ^{Tegm; ^Tigm; ^Sec1, m; ^Sec2, m; ...^Seckmax, m; ^S.I.G1, m: ^S.I.G2, m; ...^S.I.Gkmax, m^}

The different IDim images of the remote site Dm activity constituted locally at each central site Ci member of the RCGm group should be as similar as possible.

Building the local image of remote activity

The IDim image built by the active team 30 of the central site Ci and representing the activity of the remote site Dm is made from the following two operations:

- Consolidation,

- Filtered out.

Figure 8 schematically illustrates the chain of operations that make it possible to obtain the local image of remote activity.

This chain includes the following operations:

- filtering the variables resulting from the other central sites 12 of a group RCG 40 (step 70). This stage is optional.

- consolidation of the variables (data flows and number of sessions per traffic class) (step 72).

- constitution of the image ID of the activity of the remote site 14 (step 74).

- filtering the constituents of the ID image (step 76). This stage can also be optional.

- constitution of the IDF filtered image of the activity of the remote site 14 (step 78).

ID consolidation_im • Teg_m: sum of the transmission rates of data streams going towards D_m and measured by members of the RCG_m = Σ TCjD_m for all RCG Cj_m, including the central site C ,, • Tig_m: sum of the speeds of the data streams coming from D_m and measured by members of the RCG_m = Σ TC_mDj for all Cj of the RCG_m, including the central site itself C ,, • Seg_k,_m: sum of the active sessions for each class k of traffic and that goes towards D_m, measured by members of the RCG_m = Σ S_kCjD_m for all RCG Cj_m, including the central site itself C ,, • Sig_k,_m: sum of the active sessions for each class k of traffic and coming from D_m, measured by members of the RCG_m = Σ S_kC_mDj for all Cj of the RCG_m, including the central site C ,.

ID filtering_im

It may be necessary to perform a “low-pass” type of filtering on the different variables, so that irregularities and asynchronies related to the measurement periods and the elapsed information transmission times are absorbed.

ES 2 333 748 T3

Different filtering methods can be used. For example, the exponential average that allows a quick filtering in terms of its calculation and inexpensive in terms of memory and that is defined by the following formula:

VF_n = [(Q-1) * VF_n_i + V_n] * 1 / Q, with the following notation conventions:

VF_n = variable V filtered at time n

VF_n-1 = variable V filtered at time n-1

Vn = variable V before filtering at time n

Q = filtering coefficient

We will now look at IDF_im, the filtered image of remote site activity D_m as it is reconstituted by the central C, site. In order not to overload the notations, we will not modify the indices of the different constituents of IDF_im.

We observe that this filtering can also be performed on each variable received from the other central sites 12, before the calculation of the IDim image.

Precision sought

The transmission times of the exchanged information elapsed in step 54 and other sources of uncertainties (rounded, etc.) will be the cause of slight differences between the different IDF images._im of the activity of the Dm site constituted by the different Ci members of the RCGm.

However, it is necessary to ensure that these differences are as small as possible. In practice, a relative deviation of several percent will lead to good results.

Therefore, it is convenient to look for the good compromise that joins the variability of the traffic, the period of emission of the information in the RCG 40 and the filtering coefficients.

Calculation of bandwidth rules by central sites (step 58)

At this stage, each central site calculates its traffic management rules from its IDF filtered image of the global activity of the remote sites for which it is a member of the RCG and the IL image of its local activity.

We note that at this stage, there is no exchange with the other members of the RCG. Only the IL and IDF images constructed from the information regularly exchanged in step 54 are used.

This stage is made up of two main operations:

- Detection of pre-congestion

- Allocation of resources

Figure 9 schematically illustrates the chain of operations that makes it possible to obtain the calculation of the bandwidth allocation rules.

This chain includes the following operations:

- traffic measurement at the potential congestion point (step 80).

- detection of the pre-congestion state (step 82).

If a pre-congestion is detected, decide (step 84) that resources in bandwidth should be allocated to the potential pre-congestion point and generate traffic management rules (step 86).

If no pre-congestion is detected, decide (step 88) that it is not necessary to allocate resources in bandwidth to the potential pre-congestion point and remove the traffic management rules (step 90).

ES 2 333 748 T3

Detection of pre-congestion states

Site D congestion_m it is defined as a state in which the data transmission speed (input and / or output) is equal to or very close to the maximum capacity allowed by the interconnection network 10, which introduces a poor quality of service.

The method according to the invention makes it possible to anticipate these states of congestion.

For a given site, a model is established for the different congestion, leading to the following three situations in the interconnection network:

- network access to the site;

- the site's access to the network;

- the capacity of the network in transit between the site and each of the other sites.

To prevent network congestions, it is therefore necessary to detect pre-congestion states for which the data transmission rate is approaching the maximum capacity, but has not yet reached the congestion state.

The pre-congestion detection operation performed by site C_i consists of determining if there is a pre-congestion and if it is the case, determining its type among the three previous ones.

Various congestion detection principles can be used without departing from the scope of the invention. In particular, the detection can be carried out from the measurement of the effective data transmission rate or from the quality measurement as described in the applicant's patent No. 2,804,808. Furthermore, these principles can be combined.

The principle of detection by means of the measurement of data transmission rates will now be described by way of example.

It is assumed that the effective capacity of the network in the different accesses (central site, remote site, between sites) for each direction of communication is known in advance through external means (static declaration, learning, etc.).

Let the following capacities be:

- BW_eg, representing the capacity of access to the site considered in the sense of the network towards the site,

- BW_ig, representing the capacity of access to the site considered in the sense of the site towards the network,

- BW_r,_s, representing the transfer capacity from site r to site s.

Let the following relative safety margins be, within the interval [0%, 100%]: M_eg = relative safety margin to prevent congestion of network access to the site; M_ig = relative safety margin to prevent congestion of site access to the network; M_r,_s = relative safety margin to prevent congestion from site r to site s;

Let the following pre-congestion states be (Boolean, = TRUE if the pre-congestion state is detected, FALSE otherwise):

Pc_eg = pre-congestion of access to the site considered in the direction of the network towards the site;

PCig = pre-congestion of access to the site considered in the direction of the site towards the network;

Pc_r,_s = pre-congestion of the transit network from site r to site s.

ES 2 333 748 T3

To determine the different pre-congestion states, the active equipment 30 of the site C control system performs the following calculations:

Calculation of the pre-congestion states of the central site C ,:

If (Teg,) <= BW_{eg; i} * (1 - M_eg), then

Pc_{eg; i} = FALSE; yes no pc_{eg; i} = TRUE

If (Tigi) <= BW_{ig; i} * (1 - M_ig), then

Pc_{ig; i} = FALSE, if not PC_{ig; i} = TRUE

Calculation of pre-congestion states for remote site D_m:

If (Teg_m) <= BW_{eg; m} * (1 - M_eg), then

PCeg; m = FALSE; if not PC ^ = TRUE

Yes (Tig_m) <= BW_{ig; m} * (1 - M_ig), then

PCig; m = FALSE, if not PCig; m = TRUE

Calculation of pre-congestion states between central site C and remote site D_m:

If (TCiDm) <= BWi; m * (1 - Mi; m), then PCi; m = FALSE;

If not PCi; m = TRUE

If (TDmCi) <= BWm; i * (1 - Mm; i), then PCm; i = FALSE,

If not PCm; i = TRUE

Figure 10 schematically illustrates the potential congestion spots detected.

Decision to allocate resources

The allocation of resources consists of determining the best way to regulate each one of the sessions between the different sites according to the different pre-congestion states and the nature and number of these sessions.

Traffic referring to each central site 12 having multiple potential pre-congestion locations may therefore have multiple overlapping resource allocation mechanisms for this site.

- Determination of the need to allocate resources

In the case where there is no pre-congestion, it is not necessary to allocate the resources, since the traffic request is less than the network capacity.

To know if it is convenient to assign the resources to the different sessions of the users, the active equipment 30 of the site control system Ci performs the following calculations:

- Determination of the need to allocate resources for access to the central Cg site

Yes (PC_{eg; i} = FALSE), then there is no regulation of the flows entering C ,; if not, it is necessary to regulate.

If (PCig; i = FALSE), then there is no regulation of the flows leaving Ci; if not, it is necessary to regulate.

- Determination of the need to allocate resources for access to remote site D_m

Yes (PC_{eg; m} = FALSE), then there is no regulation of the flows entering D_m; if not, it is necessary to regulate.

If (PCig; m = FALSE), then there is no regulation of the flows leaving Dm; if not, it is necessary to regulate.

ES 2 333 748 T3

- Determination of the need to allocate resources between central site C and remote site D_m

Yes (PC_{i; m} = FALSE), then there is no regulation of the flows from C to D_m; if not, it is necessary to regulate.

Yes (PC_me = FALSE), then there is no regulation of the flows going from D_m to C ,; if not, it is necessary to regulate.

Bandwidth allocation

Being in this phase the principle of allocation of the identical resource for the six different potential congestion points described above, we will only describe one using the general indices x and y as:

X, y = ig, eg, i (central site) or m (remote site)

When PC_x,_Y = TRUE, there is a pre-congestion state and therefore flows need to be throttled and bandwidth allocated. This available bandwidth has BW value_{x; y} and the applicable relative safety margin is M₂. The number of active sessions for class k is S_{k; x; y}.

Different bandwidth allocation policies are possible. By way of example, a relative priority assignment device will allocate a BW part to each session_s of BW bandwidth_{x; y} available (minus the margin) proportionally to an assigned weight Pk of class k and of the global activity at the congestion point, for example with the formula:

BWs = BWx; y * (1 - Mz) * Pk * 1 / Σ (Pk * Sk; x; y)

Depending on the accepted bandwidth allocation policy, each active device 30 at the central site generates the management rules (per session, per session group ...) corresponding to each potential congestion point.

According to a fundamental characteristic of the invention:

- the detection of pre-congestion states in remote sites 14 that do not have active equipment uses an image of the traffic of this site that is reconstituted identically for active equipment 30 of the central site 12;

- the allocation of the bandwidth that refers to these remote sites 14 is calculated by each active device 30 of the central site 12 starting from the image of the totality of the traffic, even if only a part of this traffic results or comes from this central site 12 .

This allows the performance of the counter-reaction loop that comprises the following operations: bandwidth allocation, traffic measurement, pre-congestion detection and bandwidth allocation.

Stage 6

Conditioning of inbound and outbound traffic through central sites

This stage consists, for each active team 30 of the central site 12, in applying the bandwidth allocation as calculated in the previous stage, for the effective traffic that it is in charge of, that is, coming from or going to this central site. 12.

The conditioning mechanism must have at least the following characteristics:

- be able to regulate the flows resulting from the central site 12 and also the flows resulting from the remote sites 14;

- functional power at different levels of bandwidth allocation (local access, remote site 14, central site 12 to remote site 14).

Different mechanisms can be envisaged to condition traffic. Among them, we can mention the mechanism called "TCP rate control", usable if the data flows are exchanged through the TCP / IP protocol, queue management, for example "Class based queuing". This last mechanism works for all types of flow in the direction of the Central site 12 towards the Remote site 14 and for TCP / PI type flows in the direction of the Remote site 14 towards the Central site 12.

The precision of these different mechanisms is also variable.

Preferably, the method according to the invention uses a traffic conditioning solution that allows regulation at the unit session level.

ES 2 333 748 T3

Figure 11 illustrates the chaining of the traffic conditioning mechanism seen from a central site 12.

For a traffic from the central Ci to the network 10, this chaining comprises the following operations:

- conditioning of the traffic from the central site C, to the network (step 100).

- conditioning of network traffic to each remote site D_m; D_n; ... (step 102).

- traffic conditioning from central site C¡ to each remote site D_m; D_n; ... (step 104).

For network traffic towards the Ci 10 exchange, this chaining comprises the following operations:

- traffic conditioning of each remote site D_m; D_n; ... towards the central site C, (step 106).

- traffic conditioning of each remote site D_m; D_n; ... towards the network (step 108).

- conditioning of the network towards the central site C (step 110).

The method and the proposed device allow the allocation of bandwidth from a small number of central sites 12 provided with active equipment 30, while managing remote sites 14 (potentially in large numbers) and particularly in the case of mesh flows .

The invention makes it possible to avoid the need to install active equipment 30 at each remote site 14.