ES2333748T3 - PROCEDURE AND REMOTE CONTROL DEVICE OF THE CONGESTION OF FLUX FLOWS IN A TELECOMMUNICATION NETWORK IN PACKAGE MODE. - Google Patents

Abstract

The invention relates to a method for remotely controlling the congestion of meshed flow exchanged in a packet mode telecommunication network between a number N of central sites Ci provided with flow management devices and a number M of remote sites Dm devoid of such devices. According to the invention, said active devices of central sites Ci exchange between them information intended specifically for the management of flows exchanged between each of the central sites Ci and each of the remote sites Dm.

Description

Procedure and control device a distance from congestion of mesh flows in a network of Telecommunication in package mode.

Technical field

The invention is in the field of telecommunications and refers more specifically to a remote control procedure for congestion flows meshes exchanged in a telecommunication network in mode packet between a number N of central sites C_ {i} provided with flow management teams and an M number of remote sites D_ {m} that do not include such equipment.

The invention also relates to a device. intended to implement this procedure.

The invention applies regardless of the extent Geographic network, data transmission speed sent for this and the number of users of this network. In particular, It works in the case where users of the same remote site D_ {m} communicate simultaneously with several central sites C_ {i}, thus forming mesh flows.

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

Prior art

Telecommunication networks in packet mode are characterized in that the information sent is transmitted in groups called packages, consisting essentially of a header which contains the information for sending the package on the network and of the data to be transmitted. The information of addressing contained in the headings allows Identify information flows between the final applications. These packets are transmitted over the network and take, to convenience of this network, transmission and switching means very varied The technology mainly used today to These telecommunication networks in packet mode is the IP protocol (Internet Protocol). This protocol is used from start to finish and it can be transmitted over very different transmission networks, such as for example, Ethernet networks, FR (Frame Relay) networks, ATM networks (Asynchronous Transfer Mode), SDH networks (Synchronous Digital Hierarchy), SONET networks (Synchronous Optical Network), MPLS networks (Multiprotocol Label Switching) or even DWDM networks (Dense Wavelength Digital Multiplexing), etc.

Classically the packages are issued by a large number of origins that work independently of each other, to a large number of destinations that also work independently of each other.

Figure 1 shows an example of a network like is:

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

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

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" link by cable, optical, radio, etc., between the user and the provider of the access service is therefore considered part of of the access network.

Quality of service

The Quality of Service is constituted by the set of relevant features that affect the transfer of information between two given points of a network. Be specially defined by:

-

the quality of access to the service;

-

the service availability;

-

he service reestablishment time in case of failure;

-

the quality of information transfer service;

-

he information transfer time elapsed between the origin and destiny;

-

the variation of the information transfer time elapsed (Instability);

-

the degradation of transmitted information (losses, mistakes);

-

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

The geographical extension, the great use in common infrastructure equipment among many users, the variety of exchanged flows and the complexity of deployed architectures make prediction and Guarantee of the Quality of Service in such networks.

The speed of data transmission that is can transmit between two given users, the time of elapsed information transfer, variation in the time of this elapsed time (instability) and the rate of Associated loss are fundamental elements of this Quality of Service. Your control is the only thing that allows you to deploy services critical professionals (transport of voice, images, of transactions, critical data, electronic commerce, etc.).

A normal way to improve the quality of service consists of increasing the capacity of the network. But nevertheless, Given the high cost of investment and use of these networks, you want to use them to the fullest and therefore, a very expensive solution As this has a limited use.

Devices (protocols, equipment transmission, switching, routing, etc.), dependent on  the nature of the different networks can be put into practice to manage these elements of Service Quality. Based generally in priority and resource reserve mechanisms for the request (AATM, RSVP over IP ...) or for configuration (ATM, DiffServ over IP ...). These devices have in general a limited scope only to a part of the network. Being in constant mutation, interact hard.

In all cases, the result depends greatly measure of the behavior of the origin users: speed of transmission of emission data, traffic regularity, matrix of traffic, etc. This behavior is very difficult to predict, because to the wide variety of applications that networks use (voice, image transport, file transfer, database query, etc.), of the multiplicity of present users and the great variety of their needs.

Also in all cases the result depends largely from 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, to the great variety of technologies used at any given time (non-homogeneous park) and the multiplicity of organizations (service access operators, point operators 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 able to provide. In the case of networks, it is essentially bandwidth: a joint or a joint element is congested when the data transmission rate of information approaches, reaches and even tries to exceed the maximum data transmission rate that this union or this binding element is capable of transmitting without degradation (loss of information, delay ...).

Service Quality is related mainly with the congestion of the different elements of the network taken by the information during its transfer. Though there is an infinite number of gradations, a scheme of the functioning cases that these two face modes:

- Or there is no resource allocation and the network does its best to send the information to the recipient, according to the activity of the origins;

- Or there is an allocation mechanism for resources and the amount of information injected into the network for each origin is more or less controlled.

In all cases, storage systems temporary queued (memories), located at each point of multiplexing, concentration or switching, allow to treat the simultaneities of arrival of the packages. Instant rate of memory occupation that finds a package and the policy of management (priority, queue numbers, emptying rule, rejection ...) implementation at the level of each tail determine the time it has passed a package on this device, as well as its eventual rejection.

The transfer time elapsed between Two points of the network must:

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

- to the sum of the times of crossing the queues on the different teams; this elapsed time is due globally to the instant load found by each package and to the management policies of these queues.

Also, an instant load too large causes a rejection of the information package (loss); East phenomenon is the one that mainly explains the loss of packages.

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

Congestion management problem in an environment of mesh

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

Traditional congestion management

The solutions known in the prior art to allocate resources and singularly bandwidth in a point-to-point environment use, or the priority mechanism, implemented in each element of the network (router), based, or in the definition of service classes (Diffserv), or the mechanism traffic shaping from a site Central to one or more destinations. The conformation criteria they can be more or less static and more or less fine depending on the implementations WO2004066567 ("Limitation of traffic in packet-oriented networks with the help of values limit depending on the junctions for the traffic that passes the network limits ") and WO0180485 (" Optimization procedure of a network ") describe examples known in this regard.

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

A solution is also known that allows to have account for mesh flow type situations, coordinating in real time 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 of Dynamic Optimization of Service Quality in a Network of Data Transmission "No. FR 2,804,808 presented by the applicant.

This solution allows in particular to find again a predictability of returns. However, you need equip all sites, which can be shown as complex and / or expensive particularly in the case where a number reduced central sites (classically from headquarters international, national or regional and data centers (data centers) exchange information with a large number of sites  remote data users transmitted by these central sites (classically agencies), each of these being related remote sites with one or more central sites.

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

Exhibition of the invention

The invention advocates a method of remote control of congestion of exchanged mesh flows in a packet mode telecommunication network between an N number of C_ {i} central sites equipped with active management teams of flows and a number M of remote sites D_ {m} devoid of such teams, said central sites exchange with each other information specifically aimed at flow management exchanged between each of the central sites and each of remote sites

The method according to the invention comprises the following stages:

- dynamically associate each remote site with a subset of central sites based on traffic really checked,

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

- exchange between different sites central units of each group minimum traffic information in real time with each of these remote sites,

- define from the information exchanged in the previous stage a local image indicating the precongestion state for the traffic of each remote site (14),

- calculate traffic management rules for (respectively towards) each remote site depending on the image defined in the previous stage.

       \ newpage
    

       \ global \ parskip0.930000 \ baselineskip
    

Preferably, flow management It comprises the following previous stages:

- automatically configure active equipment of the central sites based on these regrouping dynamic,

- for each remote site, coordinate the teams assets of the central sites so that they are managed in time real traffic to the destination or coming from the same sites central to / from this remote site.

According to a preferred mode of implementation, The method according to the invention comprises the following stages:

In this embodiment, for each site remote and for each data exchange session of (respectively towards) this remote site, the calculation of the rules Traffic management runs locally at each central site and It comprises the following stages:

- detect precongestions close to the maximum exchange capacity of (respectively towards) east site,

- distribute transmission resources among different data exchange sessions depending on the states of precongestion detected, the nature and number of these sessions.

In a preferred embodiment variant, the execution of the traffic matrix establishment stage Dynamic is distributed among active management teams of flows from the different central sites so that each site central C_ {k}:

- determine a list of remote sites D_ {m} with whom you have exchanged information during the period of observation,

- periodically exchange this list with the other central sites,

- constitutes a base (M_ {im}) of information which is the matrix in the set of the central sites C_ {i} and of the remote sites D_ {m},

- deduces, for each remote site n, the sites exchanges (C_ {kn}) with which the remote site has exchanged information during the observation considered.

In this variant embodiment, the establishment of a dynamic traffic array is executed periodically during a first treatment loop that has a duration adapted to establish an associated traffic matrix, taking into account the overlap of all types of traffic during that period, the exchanges of information between central sites and the definition of a local image indicating the precongestion state run periodically during a second treatment loop, which has a short duration with with respect to the first treatment loop, and adapts to establish a real-time traffic matrix so that it detects in real time the different congestion states and the Traffic management rules calculation is executed periodically during a third treatment loop that has a very short duration with respect to the execution durations of the first and second treatment loop so that it is regulated in Real-time traffic depending on the type and amount of flows exchanged between central sites and sites remote

In another variant embodiment, the execution of stages a) is managed by a central management team of the Following way:

- each active team of each central site carries out an activity measurement for traffic between it and each remote site, for both directions of communication,

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

- the centralized management team deduces from for each remote site, the list of the central sites with the that exchanges information,

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

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

The invention also relates to a device. Remote control of network flow congestion exchanged in a telecommunication network in packet mode between a number N of central sites C_ {i} provided with equipment of flow management and an M number of remote sites D_ {m} devoid of such equipment, the number N of sites being small C_ {i} exchanges with respect to the number M of remote sites D_ {m}.

       \ global \ parskip1.000000 \ baselineskip
    

The device according to the invention comprises:

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

- means to exchange between different central sites of each group minimum traffic information in real time with each of these remote sites,

- means to define from the information exchanged a local image indicating the state of congestion to level of each remote site,

- means to calculate and apply rules of traffic management of (respectively to) each remote site in Image function defined.

These means to establish a matrix of traffic are arranged either at each central site or at a central management team.

Brief description of the drawings

Other features and advantages of the invention will arise from the description that follows, taken at non-limiting example title, referring 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,

Figure 3 represents a network according to model of figure 2, comprising central sites and sites remotes that implement the procedure according to the invention,

Figure 4 schematically represents flows of data exchanged between two central sites and three sites remote in the network of figure 3,

Figure 5 represents the essential stages of the method according to the invention,

Figure 6 represents a traffic matrix obtained by the process according to the invention,

Figure 7 schematically illustrates the constitution, according to the invention, of groups of central sites to from the traffic matrix in 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 calculation of bandwidth by central sites according to the invention,

Figure 10 illustrates the detection, according to the invention of a potential congestion point in the network of the figure 4,

Figure 11 schematically illustrates the traffic conditioning chain seen from a central site according to the invention.

Detailed exposition of particular embodiments

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

In this type of architecture, there are two important needs to be met simultaneously:

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

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

       \ newpage
    

Figure 3 represents a network 10 of interconnection, which uses the IP protocol for example, which interconnects a set of two central sites (C_ {i}) 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 several application servers 16 and one or more databases 18 common to several users. Central sites 12 can also understand user jobs 19. All these elements are connected to a hub or local network switch 20. A interconnection network access equipment 22, called by General 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 for remote control remote sites 14.

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

Traffic between sites

For the implementation of the procedure according to the invention, it is assumed that the main traffic through network 10 is constituted by unidirectional exchanges or bidirectional between central sites 12 and remote sites 14. Assuming that the latter are devoid of equipment assets.

Traffic on network 10 illustrates it schematically the arrows 32 of 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 flow simultaneously with several remote sites 14,

- the central sites 12 can exchange a flow simultaneously between them,

- remote sites 14 do not exchange a flow among them.

It is also considered that the traffic between different central sites 12 and 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 in the amount of information to be exchanged) and in its nature (change in the type of information that is exchange)

Control system

Each active device 30 is installed so that:

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

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

- can communicate with the other teams assets, for example, but not necessarily through the network 10;

- user traffic can be intercepted from central site 12 so that it is reorganized in case of need.

These active equipment 30 are constituted classically by:

- a central unit and dead and alive memory necessary for software execution;

- network interfaces to capture and reinject user traffic;

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

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

In a first embodiment variant, the active teams act among themselves without resorting to a device central.

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

Principles of remote control of mesh flows

In a preferred embodiment, the method according to the invention comprises the following stages:

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

- automatically configure active equipment 30 of the central sites 12 based on these regrouping dynamic,

- coordinate the active teams of the sites central 12 so that traffic is managed in real time to or from the same remote sites 14.

Remote control of mesh flows This is done by the group of active teams that They collaborate in real time.

Figure 5 illustrates the steps of an example particular implementation of the procedure according to the invention.

These stages consist of:

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

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

- exchange traffic information in real time between the active teams 30 of the central sites 12 from the same group 40 (step 54),

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

- determine traffic management rules by the active teams 30 of the central sites 12 (stage 58),

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

The stages described above are executed in three loops, a first loop 62 of medium / long term management, a second loop 64 of short-term management and a third loop 66 of Very short term control. The association of these three processes in closed loop, combined with the behavior of the network and the applications, is the one that ensures the smooth operation of the set and allows control of mesh traffics.

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

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

It's essentially about observing traffic coming and going to each remote site 14 and classifying it depending on the central site (s) 12.

We observe that in most situations real, this observation can be done over a period of time quite long (for example, a day or a week). Indeed, it look for the associated traffic matrix, that is, the matrix that reflects the overlap of all traffic in the period considered.

The determination of this traffic matrix can be performed centrally or in a decentralized manner.

In the centralized variant:

- each active team 30 of each central site 12 it carries out an activity measurement for the traffic between itself and each remote site 14, for both directions of communication,

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

- this centralized management team deduces from for each remote site 14 the list of central sites 12 with those who exchange information,

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

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

The centralized variant is well adapted for the cases in which the traffic matrix is stable, that is, that varies little over time, which is the most general case in the extent to which central sites 12 are well identified often and suffer few modifications.

In the decentralized variant, the sites C_ {12} plants are those that carry out the treatments described  previously:

Each active team 30 from central site C_ {i} 12:

- determine the list of m (where m is a integer) remote sites D_ {m} 14 with which you have exchanged information in the observation period considered for the two senses of communication,

- periodically exchange this list of sites 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}},

- deduces, for each remote site n between the M sites, the central sites k involved (M_ {kn}).

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

In the probable case of a slow evolution of the correspondences between central sites C_ {i} and remote sites D_ {m}, the period T_ {1} of emission of these flows can be kept at a very low level (for example, an exchange of infor-
every hour between central sites 12), which will not present a significant supplementary load on network 10.

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

This matrix comprises a line that contains all remote sites 14 and a column containing all the central sites 12. The intersections of each line and each column contain a "1" if those sites exchange data and a "0" if not.

Constitution of Remote Coordination Groups 40 (stage 52)

An RCG 40 Remote Coordination Group (for Remote Coordination Group) consists of:

- the identity of the remote site 14 that must controlled from central sites 12,

- the list of central sites 12 that you have traffic regularly with this remote site 14 and that should, so therefore, coordinate to ensure the best allocation of means.

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

We note that RCG 40 can be deduced directly from the traffic matrix through active equipment (see Figure 6). They evolve at the speed of this matrix (a medium / long term) and its constitution does not create a burden significant treatment internal to the system.

We also observe that traffic between sites Central 12 does not return to the notification line at this stage, since that "classic" mechanisms of Traffic control between central sites.

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

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

It takes into account the real-time aspects of traffic that refers to the array of instant traffic, the nature of this traffic and the number of active users.

An obligation of this stage consists of find the best possible balance between the next two obligations:

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

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

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

- Class 1: voice traffic - critical,

- Class 2: video traffic - level critic means, medium,

- Class 3: critical transactional traffic,

- Class 4: non-critical transactional traffic,

- Class 5: Internet traffic - level critic means, medium,

- Class 6: file transfer - critical of low level.

A "Session" is defined as the association of a user post and a server (or other post of user or between two servers ...) through network 10 and that exchange information to run a given application (telephone conversation, data transfer, access to a site Web...). The location and / or identity of the job and / or of the server and / or the application allows to match the session with your class We also observe that there can be many different sessions between two same sites. In addition, the same user post can be involved simultaneously in several sessions

Nature of the exchanges

Be the remote coordination group RCG_ {m}, relative to the remote site m. The exchanges have at least two objects: congestion detection and final regulation of the flows.

Congestion detection :

Each active team of central site C_ {i} member of this group RCG_ {m} periodically issues to other active teams in the group's central sites at least the Next information:

?

TC_ {i} D_ {m}: data flow issued by the central site i to the remote site m (bit / s),

?

TD_ {m} C_ {i}: data flow received by the central site i of the remote site m (bit / s).

Fine regulation of flows :

Each active team of central site C_ {i} group member also issues to the other active teams of The central sites of the group the following information:

?

S_ {k} C_ {i} D_ {m}: number of active sessions of class k from the central site i to the site remote s

?

S_ {k} D_ {m} C_ {i}: number of active sessions of class k from remote site m to site central i.

The emission period T3 of this information should be relatively short, as it should allow follow real-time traffic evolutions. In the networks At present, a period of About one to several seconds.

Quantification of exchanges

Assume a remote site D_ {m} so that, in a given moment:

- be active from / to C central sites C_ {i} simultaneously (the members of the RCG_ {m});

- the sessions are bidirectional from / to each of the central sites C_ {i};

- have K_ {i} active traffic classes from / to each of the central sites C_ {i};

- each TCD and TDC information have a length of L_ {t} bytes;

- each SCD and SDC information has a length of L_ {s} bytes;

       \ newpage
    

For the control of the RCG_ {m}, each central site active equipment C_ {i} involved will have to generate with a period T_ {3} a message (or a set of messages) towards each of the (C-1) others central sites, whose total length
is:

Data flow for each direction + number of active sessions for each class and for each direction = 2 * (L_ {t} + K_ {i} * L_ {s})

In total, the central site C_ {i} issues, so both, [1 / T_ {3} * (C-1) * 2 * (L_ {t} + K_ {i} * L_ {s}) * 8] bits / second of messages involving the remote site D_ {m}.

Example of digital application:

T_ {3} = 1 second

C = 4 central RCG member sites

K_ {i} = 4 active traffic classes between D_ {m} and C_ {i}.

L_ {t} = 2 bytes

L_ {s} = 2 bytes

Data flow Total messages from C_ {i} = 1 * 3 * 2 * (2 + 4 * 2) * 8 = 480 bit / s

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

       \ vskip1.000000 \ baselineskip
    

Constitution of traffic images (stage 56) Local image of the local activity

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

This stage does not need any exchange of Information with other teams.

Be a central site C_ {i}, this site is going to build the IL_ {i} image of your local activity that is constituted at least by:

?

Teg_ {i}: Speed of total data transmission from interconnection network 10 to the central site C_ {i},

?

Tig_ {i}: Speed of total data transmission from the central site C_ {i} towards the interconnection network 10,

?

Seg_ {k; i;} i: Total number of active sessions for each traffic class k and going from the network 10 of interconnection towards site C_ {i},

?

Sig_ {k; i;} i: Total number of active sessions for each traffic class k and coming from site C_ {i} towards the interconnection network 10.

       \ vskip1.000000 \ baselineskip
    

When numbering traffic classes k from 1 to k_ {max}, you get:

IL_ {i} = {Teg_ {i};

 \ hskip0.3cm 

Tig_ {i};

 \ hskip0.3cm 

Seg_ {1, i};

 \ hskip0.3cm 

Seg_ {2, i};

 \ hskip0.3cm 

... Seg_ {kmax, i};

 \ hskip0.3cm 

Sig_ {1, i}:

 \ hskip0.3cm 

Sig_ {2, i};

 \ hskip0.3cm 

... Sig_ {kmax, i}}

       \ vskip1.000000 \ baselineskip
    

Local image of remote activity

At this stage, each active site team 30 central 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 site's data flows remote 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 is used regularly the information exchanged in step 54.

       \ newpage
    

Be the central site C_ {i}, belonging to the RCG_ {m} of the remote site D_ {m}. The C_ {i} site will build the ID_ {im} image of the remote site activity D_ {m} that It is constituted at least by:

?

Teg_ {m}: Speed of data transmission that goes from the interconnection network 10 to the remote site D_ {m},

?

Tig_ {m}: Speed of data transmission from the remote site D_ {m} to the network interconnection,

?

Seg_ {k, m}: Number of sessions active for each traffic class k and going from network 10 of interconnection towards site D_ {m},

?

Sig_ {k, m}: Number of sessions active for each traffic class k and coming from site D_ {m} towards the interconnection network 10.

       \ vskip1.000000 \ baselineskip
    

When numbering traffic classes k from 1 to K_ {max}, you get:

ID_ {im} = {Teg_ {m};

 \ hskip0.3cm 

Tig_m;

 \ hskip0.3cm 

Seg_ {1, m};

 \ hskip0.3cm 

Seg_ {2, m};

 \ hskip0.3cm 

... Seg_ {kmax, m};

 \ hskip0.3cm 

Sig_ {1, m}:

 \ hskip0.3cm 

Sig 2, m;

 \ hskip0.3cm 

... Sig_ {kmax, m}}

The different ID_ {im} images of the remote site activity D_ {m} constituted locally in each central site C_ {i} member of the RCG_ {m} group should be the most similar possible.

       \ vskip1.000000 \ baselineskip
    

Construction of the local image of the remote activity

The ID_ {im} image built by the team asset 30 of the central site C_ {i} and representing the activity of the remote site D_ {m} is made from the following two operations:

- Consolidation,

- Filtered out.

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

This chain includes the following operations:

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

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

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

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

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

       \ vskip1.000000 \ baselineskip
    

ID_ {im} consolidation

?

Teg_ {m}: sum of the transmission rates of data flows that go to D_ {m} and measured by the members of the RCG_ {m} = \ Sigma TC_ {j} D_ {m} for all C_ {j} of the RCG_ {m}, including the central site itself C_ {i},

?

Tig_ {m}: sum of the speeds of data flows that come from D_ {m} and measured by the members of the RCG_ {m} = \ Sigma TC_ {m} D_ {j} for everything C_ {j} of the RCG_ {m}, including the central site itself C_ {i},

?

Seg_ {k, m}: sum of the active sessions for each traffic class k and going towards D_ {m}, measured by the members of the RCG_ {m} = \ Sigma S_ {k} C_ {j} D_ {m} for all C_ {j} of the RCG_ {m}, including own central site C_ {i},

?

Sig_ {k, m}: sum of the active sessions for each traffic class k and that comes from D_ {m}, measured by the members of the RCG_ {m} = \ Sigma S_ {k} C_ {m} D_ {j} for all C_ {j} of the RCG_ {m}, including own central site C_ {i}.

       \ vskip1.000000 \ baselineskip
    

ID_ {im} filtering

It may be necessary to filter type "low pass" in the different variables, so that absorb irregularities and asynchronies related to measurement periods and with the transmission times of information passed.

You can use different methods of filtered out. For example, the exponential mean that allows filtering fast in terms of calculation and inexpensive in terms of memory and defined by the following formula:

VF_ {n} = [(Q-1) * VF_ {n-1} + V_ {n}] * 1 / Q,

with the following conventions of notation:

VF_ {n} = variable V filtered instantly n

VF_ {n-1} = V variable filtered in the instant n-1

V_ {n} = variable V before filtering in the instant n

Q = filtering coefficient

       \ vskip1.000000 \ baselineskip
    

We will now see IDF_ {im}, the image filtered from the activity of the remote site D_ {m} just as the reconstitutes the central site C_ {i}. Not to overload the notations, we will not modify the indices of the different constituents of IDF_ {im}.

We note that this filtering can also be perform on each variable received from the other central sites 12, before the calculation of the image ID_ {im}.

       \ vskip1.000000 \ baselineskip
    

Precision sought

Information transmission times exchanged after stage 54 and other origins of uncertainties (rounded, etc.) are going to be the cause of slight differences between the different IDF_ {im} images of the site activity D_ {m} constituted by the different members C_ {i} of the RCG_ {m}.

However, it is necessary to ensure that you are 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 commitment that unites traffic variability, the period of issuance of information in RCG 40 and the coefficients of filtered out.

       \ vskip1.000000 \ baselineskip
    

Calculation of bandwidth rules by sites central (stage 58)

At this stage, each central site calculates its traffic management rules from your IDF filtered image of the global activity of the remote sites for which you are 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 images are used IL and IDF constructed from the information exchanged regularly in stage 54.

This stage is formed by two operations Main:

- Precongestion detection

- Resource allocation

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

This chain includes the following operations:

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

- precongestion state detection (stage 82).

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

If no precongestion is detected, decide (step 88) that it is not necessary to allocate resources in the width of band to the potential precongestion point and eliminate the rules of traffic management (stage 90).

Detection of precongestion states

Congestion of site D_ {m} is defined as a state in which the data transmission rate (of input and / or output) is equal to or very close to maximum capacity allowed by the interconnection network 10, which introduces a bad quality of service.

The process according to the invention allows anticipate these congestion states.

For a given site, a model is established for the different congestions taking them to the next three situations in the interconnection network:

- network access to the site;

- access of the site to the network;

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

       \ vskip1.000000 \ baselineskip
    

To prevent network congestion, you have to detect, therefore, the precongestion states for which data transmission speed is close to capacity maximum, but without having yet reached the state of congestion.

The precongestion detection operation made by the site C_ {i} consists in determining if there is a precongestion and if this is the case, determine its type among the three previous.

Several principles of congestion detection without leaving the scope of the invention. In particular, detection can be performed from the measurement of the effective data transmission rate or to from the quality measurement as described in the Patent No. 2,804,808 of the applicant. In addition, these principles are can combine

The principle of detection by means of measurement of data transmission speeds is going to describe now by way of example.

It is supposed to be known before by external media environment (static declaration, learning, etc.) the effective capacity of the network in the different accesses (central site, remote site, between sites) for each sense of communication.

Be the following capabilities:

- BW_ {eg}, representing the capacity of the access to the site considered in the sense of the network towards the site,

- BW_ {ig}, representing the capacity of the access to the site considered in the sense of the site towards the net,

- BW_ {r, s}, representing the capacity of transfer from site r to site s.

       \ vskip1.000000 \ baselineskip
    

Be the following relative margins of safety, in the range [0%, 100%]:

M_ {eg} = relative safety margin for prevent congestion of network access to the site;

M_ {ig} = relative safety margin for prevent congestion of site access to the network;

M_ {r, s} = relative safety margin for prevent congestion from site r to site s;

       \ vskip1.000000 \ baselineskip
    

Be the following precongestion states (Booleans, = TRUE if the precongestion state is detected, FALSE in the opposite case):

PC_ {eg} = precongestion of access to the site considered in the sense of the network towards the site;

PC_ {ig} = precongestion of access to the site considered in the sense of the site towards the network;

PC_ {r, s} = precongestion of the transit network from site r to site s.

       \ newpage
    

       \ global \ parskip0.950000 \ baselineskip
    

To determine the different states of precongestion, the active equipment 30 of the site control system C_ {i} performs the following calculations:

Calculation of precongestion states of the central site C_ {i}:

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

PC_ {eg; i} = FALSE; yes no PC_ {eg; i} = TRUE

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

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

       \ vskip1.000000 \ baselineskip
    

Calculation of precongestion states of the remote site D_ {m}:

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

PC_ {eg; m} = FALSE; yes no PC_ {eg; m} = TRUE

If (Tig_ {m}) <= BW_ {ig; m} * (1 - M_ {ig}), then

PC_ {ig; m} = FALSE, if not PC_ {ig; m} = TRUE

       \ vskip1.000000 \ baselineskip
    

Calculation of precongestion states between the central site C_ {i} and the remote site D_ {m}:

If (TC_ {i} D_ {m}) <= BW_ {i; m} * (1 - M_ {i; m}), then PC_ {i; m} = FALSE;

If not PC_ {i; m} = TRUE

If (TD_ {m} C_ {i}) <= BW_ {m; i} * (1 - M_ {m; i}), then PC_ {m; i} = FALSE,

If not PC_ {m; i} = TRUE

Figure 10 schematically illustrates the points of potential congestion detected.

       \ vskip1.000000 \ baselineskip
    

Decision to allocate resources

The allocation of resources consists of determine the best way to regulate each of the sessions between  the different sites depending on the different states of precongestion and the nature and number of these sessions

The traffic that refers to each central site 12 that has several potential places of precongestion, can, therefore, have several resource allocation mechanisms that overlap for this site.

       \ vskip1.000000 \ baselineskip
    

- Determination of the need to allocate resources

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

To know if it is convenient to assign the resources to different user sessions, the active team  30 of the site control system C_ {i} performs the following calculations:

       \ vskip1.000000 \ baselineskip
    

- Determination of the need to allocate resources for the access to the central site C_ {i}:

If (PC_ {eg; i} = FALSE), then there is no regulation of the flows entering C_ {i}; if not, it is necessary regular.

If (PC_ {ig; i} = FALSE), then there is no regulation of the flows that leave C_ {i}; if not, it is necessary regular.

       \ vskip1.000000 \ baselineskip
    

- Determination of the need to allocate resources for the access to remote site D_ {m}

If (PC_ {eg; m} = FALSE), then there is no regulation of the flows entering D_ {m}; if not, it is necessary regular.

If (PC_ {ig; m} = FALSE), then there is no regulation of the flows that leave D_ {m}; if not, it is necessary regular.

       \ global \ parskip1.000000 \ baselineskip
    

- Determination of the need to allocate resources between the central site C_ {i} and remote site D_ {m}

If (PC_ {i; m} = FALSE), then there is no regulation of flows ranging from C_ {i} to D_ {m}; if not, does lack regular.

If (PC_ {m; i} = FALSE), then there is no regulation of flows ranging from D_ {m} to C_ {i}; if not, does lack regular.

       \ vskip1.000000 \ baselineskip
    

Bandwidth Assignment

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

\hskip0.2cm

o

\hskip0.2cm

m (sitio remoto)X, y = ig, eg, i (central site)

 \ hskip0.2cm 

or

 \ hskip0.2cm 

m (remote site)

When PC_ {x, y} = TRUE, there is a state of precongestion and, therefore, it is necessary to regulate the flows and assign bandwidth This available bandwidth has BW_ {x; y} value and the applicable relative safety margin is M_ {2}. The number of active sessions for class k is S_ {k; x; y}.

Different policies for assigning the width of Band are possible. As an example, a device of allocation by relative priority will attribute to each session a part BW_ {s} of available BW_ {x; y} bandwidth (minus margin) proportionally to an assigned weight P_ {k} of class k and of the global activity at the point of congestion, for example with the formula:

BW_ {s} = BW_ {x; y} * (1 - M_ {z}) * P_ {k} * 1 / \ Sigma_ {k} (P_ {k} * S_ {k; x; y})

Depending on the width allocation policy of accepted band, each active equipment 30 of the central site generates management rules (per session, per session group ...) corresponding to each potential congestion point.

According to a fundamental characteristic of the invention:

- detection of precongestion states at remote sites 14 that do not have active equipment use a traffic image of this site that is reconstituted of identical manner for active equipment 30 of central site 12;

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

This allows the realization of the loop of Counterreaction comprising the following operations: allocation  bandwidth, traffic measurement, precongestion detection and bandwidth allocation.

Stage 6

Conditioning of incoming and outgoing traffic by central sites

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

The conditioning mechanism must have the minus the following features:

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

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

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

The accuracy of these different mechanisms It is also variable.

Preferably, the process according to the invention uses a traffic conditioning solution that allows to regulate at the level of the unit session.

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

For a traffic from central C_ {i} to the network 10, this chain includes the following operations:

- site traffic conditioning central C_ {i} towards the network (step 100).

- conditioning of network traffic towards each remote site D_ {m}; D_ {n}; ... (step 102).

- site traffic conditioning central C_ {i} to each remote site D_ {m}; D_ {n}; ... (stage 104).

For a network traffic to the central C_ {i} 10, this chain includes the following operations:

- traffic conditioning of each site remote D_ {m}; D_ {n}; ... towards the central site C_ {i} (stage 106).

- traffic conditioning of each site remote D_ {m}; D_ {n}; ... towards the network (step 108).

- network conditioning to the site central C_ {i} (step 110).

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

The invention avoids the need for install an active device 30 at each remote site 14.

Claims (12)

1. Remote control procedure for congestion of mesh flows exchanged in a telecommunication network in packet mode between a number N of central sites C_ {12} provided with active flow management equipment and a number M of sites remote D_ {m} (14) devoid of such equipment, said central sites exchanging (12) among them information specifically aimed at managing the exchanged flows between each of the central sites (12) and each of the remote sites ( 14), a procedure characterized in that it comprises the following stages: - dynamically associate each remote site (14) with a subset of central sites (12) based on traffic really checked, - establish a dynamic traffic matrix that indicate, for each remote site (14), the group of central sites (12) that exchanges data with this remote site (14) during a given observation period, - exchange between different sites exchanges (12) of each group minimum traffic information in real time with each of said remote sites (14), - define from the information exchanged in the previous stage a local image indicating the precongestion state for the traffic of each remote site (14), - calculate traffic management rules for (respectively towards) each remote site (14) depending on the Image defined in the previous stage.

         \ vskip1.000000 \ baselineskip
      

2. Method according to claim 1, characterized in that said flow management comprises the following previous steps: - automatically configure active equipment of flow management (30) of the central sites (12) based on these dynamic regrouping, - for each remote site (14), coordinate the active equipment (30) so that it is managed in real time traffic to or from the same central sites to / from this remote site (14).

         \ vskip1.000000 \ baselineskip
      

Method according to claim 2, characterized in that, for each remote site (14) and for each data exchange session of (respectively towards) this remote site (14), the calculation of the traffic management rules is executed locally at each central site (12) and comprises the following stages: - detect precongestions close to the maximum exchange capacity of (respectively towards) east site, - distribute transmission resources among different sessions depending on precongestion states detected, of the nature and number of these sessions.

         \ vskip1.000000 \ baselineskip
      

Method according to claim 1, characterized in that the execution of the establishment of a dynamic traffic matrix is distributed among the active flow management teams (30) of the different central sites (12) so that each central site C_ {k }: - determine a list of remote sites D_ {m} with whom you have exchanged the information during the period of observation, - periodically exchange this list with the other central sites C_ {i} (12), - constitutes a base (M_ {im}) of information which is the matrix in the set of central sites C_ {i} (12) and from remote sites D_ {m} (14), - deduces, for each remote site n (14), the central sites (C_ {kn}) (12) with which remote site n has exchanged information during the observation considered.

         \ vskip1.000000 \ baselineskip
      

5. Method according to claim 1, characterized in that the establishment of the dynamic traffic matrix is periodically executed during a first treatment loop that has a duration adapted to establish an associated traffic matrix, taking into account the superposition of all types of traffic traffic during that period. Method according to claim 1, characterized in that the exchanges of information between the central sites (12) and the definition of a local image indicating the state of precongestion are executed periodically during a second treatment loop that has a duration adapted to establish an array of real-time traffic so that different congestion states are detected in real time. Method according to claim 1, characterized in that the calculation of the traffic management rules is periodically executed during a third treatment loop that has a very short duration with respect to the execution times of the first and second treatment loops in a manner that traffic is regulated in real time, depending on the type and quantity of flows exchanged between central sites (12) and remote sites (14). Method according to claim 1, characterized in that the establishment of a dynamic traffic matrix is managed by a central management team as follows: - each active team (30) of each central site (12) carries out an activity measurement for traffic between the same and each remote site (14), in both directions of communication, - the centralized management team collects periodically traffic information on all computers assets (30) of each central site (12), - the centralized management team deduces from for each remote site (14) the list of central sites (12) with whom you exchange information, - the centralized management team communicates to active team (30) of each central site (12) said lists.

         \ vskip1.000000 \ baselineskip
      

Method according to one of claims 1 to 8, characterized in that the number N of central sites C_ (12) is less than the number M of remote sites D_ (14). 10. Remote control device for the congestion of mesh flows exchanged in a telecommunication network in packet mode between a number N of central sites C_ {i} (12) provided with active flow management equipment (30) and a number M of remote sites D_ {m} (14) not comprising such equipment, a device characterized in that it comprises: - means to establish a traffic matrix which indicates, for each remote site (14), the site group exchanges (12) that exchange data with this remote site (14) during a given observation period, - means to exchange between different central sites (12) of each group minimum information on the real-time traffic with each of these remote sites (14), - means to define from the information exchanged a local image indicating the state of congestion to level of each remote site (14), - means to calculate and apply rules of traffic management of (respectively to) each remote site (14) depending on the defined image.

         \ vskip1.000000 \ baselineskip
      

Device according to claim 10, characterized in that said means for establishing a traffic matrix are arranged in each central site (12). 12. Device according to claim 10, characterized in that said means for establishing a traffic matrix are arranged in a central management equipment arranged in the network (10).