EP1616414A2

EP1616414A2 - Method and device for controlling data packet traffic at the input of a network

Info

Publication number: EP1616414A2
Application number: EP04742535A
Authority: EP
Inventors: Gérard Babonneau; Wissem Loudhaief
Original assignee: France Telecom SA
Current assignee: Orange SA
Priority date: 2003-04-18
Filing date: 2004-04-16
Publication date: 2006-01-18
Also published as: WO2004095783A2; WO2004095783A3; FR2854018A1; US20070058548A1; US7542417B2

Abstract

The invention relates to a method of controlling data packet traffic at the input of a network, whereby the traffic comprises N streams and/or substreams which are each associated with a priority level, N = 2, and each of the aforementioned packets is marked with the priority level associated with the stream or substream to which said packet belongs. The inventive method comprises a step employing a token bucket mechanism with N operating levels and N token buffers each containing a number of available tokens, the tokens of each of the N token buffers being used to process one of the N priority levels. Moreover, each of the packets is accepted or refused according to whether or not it is possible for same to be attributed tokens depending on the tokens available at least in the token buffer which is used to process the priority level of each packet. In one particular embodiment of the invention, the tokens from the N token buffers are shared between the N priority levels, and a packet with priority level i can be attributed tokens from a token buffer which is associated with priority level j, said level having less priority, when there are not sufficient tokens available in the i priority level token buffer.

Description

Method and device for controlling data packet traffic entering a network, computer program and corresponding network equipment.

The field of the invention is that of communication networks, and in particular but not exclusively of networks of IP type or equivalent. More specifically, the invention relates to a method for controlling traffic of data packets entering a network, in the case where the traffic comprises a plurality of streams and / or substreams each associated with a priority level , and where each of the packets is marked with the priority level associated with the stream or substream to which this packet belongs. In other words, the invention relates to a network mechanism making it possible to optimize the flow of incoming traffic on a network.

The invention has numerous applications, such as for example the control of multimedia streams (for example MPEG streams), alone or by aggregates, or even the control of a multiplex of streams of different natures (for example a video stream / multiplex audio with a TCP stream, on an ADSL access). We now briefly present the network context in which the present invention is situated.

The increase in computer performance as well as the speeds offered by new generations of networks open the way to new services based on multimedia streams. In fact, the number of audiovisual information transmitted over networks (for example of the IP type ("Internet Protocol")) is constantly increasing, and the compression algorithms (for example of the MPEG type ("Moving Picture Experts Group")) improve, providing better quality with lower flow rates. However, today the level of quality is not always acceptable. If each link in the chain has the intrinsic capacities to provide this quality, putting them end to end and the sharing of IP network resources by many users sometimes lead to poor results.

In general, the transmission of information in an IP network relies on the transport layer for quality control between the source and the receivers. This layer, located between the routing and the applications, is traditionally carried out by the TCP protocol (“Transmission Control Protocol”). From an application point of view, TCP takes care of retransmitting lost or bad information received, by session level control. From a network point of view, certain protocol parameters make it possible to detect possible congestion, and to adapt the bit rate of the source to the constraints of the network. The objective is then to limit the speed if the network cannot handle everything, and to avoid sending packets which will be lost. Many studies today seek to apply equivalent mechanisms to video streams, with the real-time constraint of a dynamic adaptation of coders to the available bit rate.

But due to the significant reaction time between one or more clients and the video source, the real-time and audiovisual protocols currently do little processing, and are mainly limited to marking the transmission time and the encapsulation of packets of the application for their routing in the IP layer (for example RTP / UDP), in charge of the applications to cope with the received data.

The evolution of networks offers the possibility of managing "quality of service"

(QoS) in routers. However, it is relevant to note that this is the place where most of the losses of IP networks occur, and mechanisms are implemented at this level to selectively process the different flows in order to best ensure the objectives of quality. The means deployed to improve the quality of the flows transmitted are the subject of the work of the “IntServ” (for “integrated services”, ie “integration of services”) and “DiffServ” (for “differentiated services”) groups. ”, That is to say“ differentiated services ”) at the IETF (Internet Engineering Task Force):

- “IntServ” defines means for reserving a resource with guaranteed speed between two nodes of a network;

- "DiffServ" defines means for dynamically controlling the flow of flow aggregates as a function of the network load. Compared with end-to-end solutions (analogous to TCP) solutions located in routers have several advantages:

- they are free from any session constraints;

- they are also adapted to real time, because their action in the routers is immediate without requiring feedback from users; - They are therefore naturally suitable for selective broadcasting (“multicast”), since they are independent of the number of users fed by the flow and independent of reports from a variable number of users.

Processing in routers is based on a distinction between packets arriving in routers supporting “quality of service” (QoS, “Quality of Service”) mechanisms.

This distinction naturally exists in MPEG streams, because the compression of MPEG video streams results in a series of data of different natures and not independent. There are three types of images: I, P and B. Type I (Intra) images are each coded without reference to another image, compression being limited to the reduction of spatial redundancies within each image. To optimize the amount of information transmitted, MPEG coders exploit the fact that two consecutive images are generally little different. A motion detection only considers the part which has just changed with respect to the previous image to obtain information of reduced size coded in a P-type image (Predicted).

Other means make it possible to obtain even more reduced information by interpolating the movements between two type I or P images; these images are then type B (Bidirectional).

The size of the images P is generally much smaller than that of the images I, and coding with few I images makes it possible to obtain, at equivalent bit rate, a much higher decoding quality. Under these conditions, the loss of an image is not equivalent depending on the nature of the information it contains. This structure of information must lead to considering the importance or the weight of each piece of information in its processing by the network. There are two reasons for keeping images I:

- periodic re-synchronization of the flow in the event of losses;

- any change of scene because it is no longer possible to rely on the previous images for movement coding.

Another way of considering this weight of information is to split an MPEG4 stream into several hierarchical levels to obtain a variable quality according to the overall content received by the user. A hierarchical level N must be supported on the presence of the Nl lower levels to provide additional quality. An elementary case is to consider a video made up of a basic stream (containing I and P images) and of an enhancement stream (containing P and B images). For this elementary case, the basic flow as a whole is considered to have higher priority than the enhancement flow.

The distinction in the nature of images or streams in MPEG traffic should be used in the "DiffServ" routers to selectively process the different information in a video stream:

- either by marking the TOS (“type of service”, ie “type of service”) or DSCP (“Differentiated Services Code Point”, ie

"Markup value for differentiated services") of packets by the video server,

- or by a classification carried out by the router, which also results in a marking of IP packets. In this document, we consider that the marking of packets is possible in all cases. The means of carrying out this marking are considered to be well known to those skilled in the art. They are therefore not discussed in detail.

When a congestion situation appears in a router, the received packets are discarded according to the load and their priority level. An important characteristic of the data contained in these packets is their significant variation depending on the content of the scene. However, the most critical information for the restitution to the user is contained in the largest bursts, and the main problem of IP networks of the “Best effort” type (that is to say without guarantee) is their difficulty. to let the gusts pass in case of congestion. Therefore, the simple marking of the elementary streams of an MPEG stream is not sufficient for their optimal processing. Indeed, the usual "DiffServ" mechanisms are designed to accept bursts that are usually found in IP networks, with the applications that are in the majority today: the transfer of URLs ("Uniform Resource Locator") for WEB applications and file transfers by FTP ("File Transport Protocol"). All these applications use the TCP protocol, the mechanisms have been the subject of numerous studies in order to obtain a gradual increase in load, and an adaptation of the flow according to the load of the network.

However, video streams question this functioning because their behavior is qualified as aggressive, insofar as they generally ignore the state and the load of the network. In addition, most of the mechanisms introduced into IP networks all have the objective of smoothing flows to promote a smooth flow of traffic. Paradoxically, coders provide better quality when they produce variable rate flows, which are the most abused in IP networks.

The introduction of video streams into the IP network therefore faces three contradictions:

- increase the quality of coding, leading to a defined average bit rate, to produce bursts of packets when the coded sequence requires it;

- access networks offer a limited maximum bandwidth (including ADSL (“Asymmetry Digital Subscriber Line”) because applications are tempted to exploit an average speed close to the maximum to provide the best quality to users;

- the bursts are the most important information because they correspond to a change of scene or at least to a significant change in the content of the image. Very often, these images are of type I (Intra) whose loss is very critical, because it becomes impossible to reproduce the following images, even if the latter are correctly received. We now present the known traffic conditioning techniques aimed at reducing congestion in networks.

First of all, it should be noted that work on the application of formatting for MPEG flows in IP networks based on UDP and RTP as transport protocols is very rare. The majority of work concerns ATM networks

("Asynchronous Transfer Mode") and the use of TCP as a transport protocol.

Traffic shaping and conditioning mechanisms are used in “quality of service” (QoS) IP networks. We can in particular refer to the document “Traffic Shaping for MPEG video transmission over next generation internet ”(traffic shaping for transmission of MPEG video over the next generation internet), MF Alan, M. Atiquzzaman, MA Karim. In this document, traffic smoothing (TS) is used to ensure the conformity of MPEG flows to the TSPEC ("Traffic Specifier", ie "traffic specification") necessary for the reservation of resources in networks " IntServ ". For "DiffServ" networks, the processing is done by flow aggregate and therefore without worrying too much about the applications. Traffic smoothing (TS) algorithms are however widely used in coding in order to control the bit rate of coders. This remains insufficient to control flows at the network level. The use of formatting, by traffic smoothing (TS, for "Traffic

Shaping ") or traffic rule control (or TP, for" Traffic Policing "), to reduce congestion in the network can significantly improve the level of" quality of service "(QoS) that the network is capable to deliver to applications.

Smoothing (TS) smoothes the bursts by “buffering” (that is to say by buffering) the packets concerned by the excess of bursts in the border equipment of the network. It can reduce congestion to acceptable levels, especially that scheduling algorithms such as CBQ (“Class Based Queuing” ie “management of queues based on service classes) ”) Or PQ (“ Priority Queuing ”that is to say“ queue management by priorities ”) are not able to do this. Used alone, these mechanisms propagate bursts in the network.

Like smoothing (TS), traffic rule control (TP) limits the traffic rate to the configured rate. But instead of "buffering" packets like smoothing (TS), non-compliant packets are either rejected or noticed to lower their priorities. Traffic rule control (TP) therefore does not smooth traffic, but it does not introduce a "buffering" delay either.

In the majority of architectures that support "quality of service" (QoS), a service contract exists between the network service provider (NSP, for "Network Service Provider") and the application provider (ASP, for " Application Service Provider ”). In ATM networks, this contract is called "Traffic contract". In the "DiffServ" networks, the contractual aspects are dealt with in the SLA ("Service Level Agreement") and more specifically in the SLS ("Service Level Specification").

We also know the following document: RFC2475, "An Architecture for Differentiated Services", December 1998. It specifies that traffic sources can perform classification and classification tasks. traffic conditioning. Indeed, traffic can be marked before leaving the source domain. This initial marking is called "Initial Marking" or "Pre-marking". The advantage of initial tagging is that application preferences and needs can be better taken into account when deciding which packets should receive better processing in the network.

Preventing overloading of a given service class is not an easy task in "DiffServ" networks. In addition, in the event of an overload in a class of service, it should be noted that all the flows of this class of service suffer from a degradation of the “quality of service” (QoS). In addition, several mechanisms used in the implementation of "DiffServ" work less efficiently in the presence of gusts. The RED (“Random Early Drop”) mechanism, for example, is more effective when applied to smooth traffic, otherwise it is the smooth flows which are penalized while the burst flows do not undergo a significant improvement. MPEG streams are characterized by the fact that they present bursts (nature

"Bursty") and their sensitivity to packet loss. These losses cause a degradation of the subjective quality, but it is very difficult to predict the level of this degradation following losses. This degradation is strongly linked to the nature of the information transported by the lost packets. Error correction mechanisms are used during decoding to compensate for losses.

Managing MPEG flows in the network, or even in the end routers (ER, for "Edge Router"), is a complicated task. The network service provider (NSP) is not required to treat MPEG streams differently. In addition, the traffic aggregate resulting from several audio-visual streams is generally difficult to describe: - the packet arrival process is self-similar;

- large variation in the data transported by the packets; - the dynamics of the protocols.

One solution is to mark the packets and assign them the appropriate level of "quality of service" (QoS) before they leave the domain of the Internet service provider (ISP). The media access gateway (MAG, for “Media Access Gateway”) is for example responsible for this task. This MAG gateway manages traffic according to the specified SLS. This approach facilitates the negotiation of SLA / SLS for services in continuous mode (“Streaming”) and imposes on the client a very specific traffic profile.

Among the current techniques, the most widespread for controlling traffic is the WRED (Weighted Random Early Drop) mechanism which consists of a random and different packet loss depending on the marking of the packets. This mechanism is based on an average filling rate of the transmission queue on a network link. However, this technique introduces a random nature of packet rejections, and the filling rate of the queue is not optimized. Depending on the size of the bursts and their frequency, these rejections can occur for a low filling or a very high filling of the queue. This leads on the one hand to an underuse of the queue, and on the other hand to the reservation of consequent memory size for the realization of this queue. This problem exists for any type of application, and it is even more real for audiovisual streams because of their large bursts.

To detail this point, it is fundamental to note first of all that the bursts of video streams are unpredictable, both in size and in duration, while guaranteeing an average bit rate over a period of the order of one second. This window for calculating the average throughput is far too large to obtain reasonable sizes of the associated queues. In fact, the routers react by calculating the filling averages over ten packets received, while certain bursts can greatly exceed 20 packets.

Thus, a succession of bursts can lead to rejections by saturation of the capacity of the queue, inhibiting the normal operation of the mechanism. Conversely, when light traffic occurs after a series of gusts, the average value may remain temporarily abnormally high and packets are dropped while the queue is almost empty.

The WRED mechanism is therefore not suitable for controlling flows characterized by an average value over a fixed duration. The invention particularly aims to overcome these drawbacks of the prior art and offer an optimal solution in the event of network congestion.

More specifically, one of the objectives of the present invention is to provide a method and a device for traffic control making it possible to control gusts and to smooth traffic over a set of flows and / or substreams associated with levels of priorities.

In other words, an objective of the present invention is to provide a method and a device for traffic control making it possible to protect the important information from the bursts, in order to provide a solution to the contradiction between the optimization of a stream (for example a video stream) containing bursts and smoothing the bursts for quality transport in the network.

The invention also aims to provide such a method and device which are simple to implement and inexpensive.

Another objective of the invention is to provide such a method and device making it possible to efficiently offer traffic contracts (SLA / SLS) between network operators and service providers.

These various objectives, as well as others which will appear subsequently, are achieved according to the invention using a method for controlling a traffic of data packets entering a network, the traffic comprising N stream and / or substream each associated with a priority level, N> 2, each of the packets being marked with the priority level associated with the stream or substream to which said packet belongs, said method comprising an implementation step an N-level token bucket mechanism with N token buffers each containing a number of available tokens, the tokens of each of the N token buffers being used to process one of the N levels of priority, each packet being accepted or refused depending on whether or not it is possible to allocate tokens according to it tokens available at least in the token buffer used to process the priority level of said packet.

The general principle of the invention therefore consists in using a multi-level token bucket (MLTB, for “Multi Layer Token Bucket”) to reject packets outside a required profile and characterized by the N operating levels of the bucket multi-level tokens. Each packet undergoes processing according to a marking corresponding to its priority level. Accepted packets are placed in a queue.

The multi-level token bucket makes it possible to selectively and jointly process several levels of flow priorities. It is well suited to characterizing traffic between the size of incoming gusts and the flow of outgoing traffic. We know that in the event of network congestion, it is illusory to seek available bandwidth. The adjustment of the parameters of the multi-level token bucket ensures a relationship between the priority levels to balance the operating constraints between the flow rates by priority levels and the bursts acceptable by the token bucket according to the constraints of the transported applications. The characterization of the parameters of the N sets of parameters of the multi-level token bucket allows numerous solutions and can be adapted to almost all operating cases:

- an extreme case is the behavior with N sets of independent parameters acting like buckets with independent tokens; - another extreme case is the possibility for the highest priority level to take all the tokens and result in a rejection of the packets from all the other levels;

- between these two extremes, all the configurations are possible, allowing more or less gusts or more or less reserved flow per level. The invention therefore makes it possible to process bursts on the highest priority levels, because there is for each priority level a reserve available to prevent any sudden arrival of a set of data which must not be rejected.

Remember that a usual token bucket has only one operating level (it has a single set of parameters) and therefore processes all packets indiscriminately. Packets are therefore dropped in the event of network congestion regardless of their priority level.

Note that the present invention is fully compatible with IP streams "unicast" (single recipient) and "multicast" (selectively broadcast). It will also be noted that the present invention makes it possible to transmit several groups of flows with different priorities in the same class of service. In particular, the invention makes it possible to provide processing adapted to one or a group of video streams (IPB or hierarchical) in accordance with a contracted traffic profile (SLS) by characteristic values of the token bucket type. Indeed, the easily measurable and adaptable parameters of a multi-level token bucket (MLTB) are an effective means of proposing traffic contracts (SLA / SLS) between network operators and service providers. The presence of priority information leads to the specification of this bucket. The multiple versions of this bucket are a means of offering classes of services adapted to customer requirements. Whatever the applications, the traffic profile involves the main elements of characterization of a flow in a network: the speed and the delay. The invention is therefore a means of defining a contract with a negotiated compromise between the speed, the size of the bursts, and the transmission time.

In a first advantageous application of the invention, the traffic comprises N sub-flows each corresponding to one of the N hierarchical levels of a hierarchical flow or of an aggregate of hierarchical flows.

It is for example an audio / video hierarchical stream comprising the following substreams: an audio substream, a basic video substream and an enhancement video substream. In a second advantageous application of the invention, the traffic comprises N sub-streams each corresponding to one of the N types of images of a multimedia stream or of an aggregate of multimedia streams.

It is for example an MPEG video stream comprising three substreams corresponding to the three types of images I, P and B. In a third advantageous application of the invention, the traffic comprises N streams each corresponding to one of the stream of a multiplex of at least two streams. This is for example a multiplex video / audio stream with a TCP stream, on an ADSL access.

Advantageously, the traffic comprises N flows and / or substreams belonging to the same class of service. Thus, the invention, thanks to the multi-level token bucket, makes it possible to transmit several flows and / or sub-flows with different priorities in the same service class. We can distinguish several service classes, such as for example the "streaming" class (containing audio and video streams, the "priority TCP" class, the "Best IP network effort" class, ...) and use a bucket with multi-level token for each class. Each class of service can be defined by marking packets, by the source or destination IP address of the packets, by the protocol used for the packets, etc.

Preferably, the refused packets are discarded.

The packets refused are those which do not comply with the traffic profile defined by the parameters of the N operating levels of the multi-level token bucket.

Another option, less efficient but which nevertheless falls within the scope of the present invention, is to transmit the refused packets after having marked them again with a lower priority level. However, this option has the disadvantage of increasing the probability of packet rejection in congested network nodes.

Advantageously, the network is of IP type or equivalent.

According to an advantageous characteristic, each of the N operating levels of the token bucket mechanism is managed by a regulator bi (r _b bπi;), i G {1 to N}, with: r _j the nominal flow rate of the regulator; - bn; the maximum size of the controller token buffer; bi (t) the instantaneous value of the filling of the regulator token buffer.

Preferably, the tokens of the N token buffers are shared between the N priority levels, a packet of priority level i being able to be allocated tokens of a token buffer associated with a priority level j less priority when the tokens available in the token buffer of priority level i are not sufficient.

In this way, we favor the bursts of the highest priority levels.

Advantageously, for each priority level apart from the highest priority level, it guarantees a quantity of tokens reserved exclusively for packets having said priority level.

Thus, a minimum resource is guaranteed for each priority level, without excluding a partially shared use of the resources (ie tokens of the different operating levels of the multi-level token bucket). In a first particular embodiment of the invention, the allocation of tokens to a packet of priority level i is carried out according to a discontinuous mode per packet and consists in assigning: either tokens available in the token buffer memory of priority level i; - or tokens available in a token buffer of priority level j with lower priority, when the tokens available in the buffer of tokens of priority level i are not sufficient.

Thus, in the discontinuous mode, a packet can use resources (tokens) only on one level of operation of the multi-level token bucket. In a second particular embodiment of the invention, the allocation of tokens to a packet of priority level i is carried out in a continuous mode per bit and consists in allocating: tokens available in the buffer of level tokens of priority i; and in addition to the tokens available in at least one buffer of tokens of priority level j with lower priority, when the tokens available in the buffer of tokens of priority level i are not sufficient.

In other words, in the continuous mode, a packet can use the resources (tokens) of several operating levels of the multi-level token bucket at a time.

Advantageously, the packets accepted by the token bucket mechanism with N operating levels are placed in a queue. The method further includes a step of implementing a token bucket mechanism at a single level of operation with a single token buffer, so as to take the packets contained in the queue and send them over the network by performing traffic smoothing by limiting the instantaneous speed to a value acceptable by the network . The single-level token bucket (TBTS, for “Token

Bucket Traffic Shaper ”) therefore makes it possible to limit the peak bit rates emitted by the network equipment supporting the invention. It delays gusts when they exceed the tolerated flow in the network.

We use for example a memory zone, whose input is managed by the multi-level bucket (burst control) and whose output is managed by the bucket at one level

(traffic smoothing).

The invention also relates to a computer program comprising program code instructions for executing the steps of the method as mentioned above, when said program is executed on a computer. The invention also relates to a device for controlling a traffic of data packets entering a network, the traffic comprising N streams and / or substreams each associated with a priority level, N> 2, each of the packets being marked with the priority level associated with the stream or sub-stream to which said packet belongs, said device comprising means for implementing a token bucket mechanism with N operating levels with N token buffer memories each containing a number of tokens available, the tokens of each of the N token buffer memories being used to process one of the N priority levels, each of the packets being accepted or refused according to whether or not it is possible to assign tokens to it according to the tokens available at least in the token buffer memory used to process the priority level of said packet.

Preferably, said method comprises means for sharing the tokens of the N token buffer memories between the N priority levels, a packet of priority level i being able to be allocated tokens from a token buffer associated with a lower priority level j when the tokens available in the token buffer of priority level i are not sufficient. Advantageously, for each priority level apart from the highest priority level, said sharing means comprise means for guaranteeing a quantity of tokens reserved exclusively for packets having said priority level. The invention also relates to network equipment comprising a control device as mentioned above, said network equipment belonging to the group comprising: network equipment located between a network of an application or service provider and a network of a provider of 'a network service, constituting said network at the input of which is carried out the control of a data packet traffic; - routers included in nodes of a network of a network service provider, constituting said network at the input of which is carried out the control of a traffic of data packets

Other characteristics and advantages of the invention will appear on reading the following description of a preferred embodiment of the invention, given by way of non-limiting example, and the accompanying drawings, in which: FIG. 1 presents an example of network architecture in which the traffic control method according to the invention can be implemented; FIG. 2 illustrates a particular embodiment of the method according to the invention, implementing two functions, based on the use respectively of a multi-level token bucket and a single-level token bucket; FIG. 3 illustrates a regulator managing an operating level of the multi-level token bucket illustrated in FIG. 2, as well as the use in this regulator of a parameter K _j guaranteeing a minimum of resource for the priority level associated with this regulator; FIG. 4 illustrates an example of allocation of tokens in the case where the operation of the multi-level token bucket is described with independent buffer memories (buffers); FIG. 5 illustrates an example of allocation of tokens in the case where the operation of the multi-level token bucket is described with correlated buffers. The invention therefore relates to a method for controlling data packet traffic entering a network. The traffic is of the type comprising N streams and / or substreams each associated with a priority level, with N> 2. Each of the packets is marked with the priority level associated with the stream or substream to which it belongs. By way of example, the invention makes it possible to transmit, as a priority, the essential information of a video stream, or of several video streams grouped in an aggregate. Depending on the nature of the flow, this distinction is for example possible either by IBP type images (see definition above), or by the n layers of a hierarchical flow. If in the first case the average bit rate of the images I remains low compared to the global bit rate, in the second case the most important information and to be protected as much as possible is defined by the fraction of the global bit rate occupied by the base layer, and which can represent up to 50% of the flow. In general, the base layer is the only one to contain the reference information contained in the images I.

In an aggregate, all data with the same priority level is treated the same. For example, all basic streams or all I frames are treated as a single higher bit rate stream than a single video.

We now present, in relation to FIG. 1, an example of network architecture in which the traffic control method according to the invention can be implemented. In this example, we consider the case of service providers (ISP, for

"Internet Service provider") offering a streaming video transmission service.

The example of (simplified) architecture illustrated in Figure 1 includes:

- an IP network of type "DiffServ" 1, managed by a network operator (also called network service provider, or NSP (for "Network service

Provider ")) and comprising a plurality of routers 2 _{ to 2 ₅ included in nodes of the IP network;

- two networks of “streaming” service providers 3 and 4, one comprising two servers 5 and 6, and the other a server 7. Each network of service providers 3, 4 also comprises end equipment 8 , 9 connected to one of the routers on the IP network, called the edge router 2 ,, which is responsible for sending data from a server to a main route of an IP core network;

- two client terminals 10 and 11, each connected to the IP network 1 for example via an ADSL link 12, 13. It is assumed that there are two traffic contracts (symbolized by the arrows referenced SLAl and SLA2 respectively in FIG. 1): one between the operator of the IP network 1 and the service provider whose network is referenced 3, and the other between the operator of the IP network 1 and the service provider whose network is referenced 4.

The method according to the invention is implemented in network equipment forming a traffic conditioner for entry into the IP network 1. This network equipment can be located between the network of the service provider 3, 4 and the IP network 1 :

- either in one of the end devices 8, 9 of the networks of service providers 3 and 4;

- or in the end router 2, of the IP network 1. The network equipment implementing the method according to the invention can also be any router placed at a congestion point in the network (in particular for any access to an ADSL link).

We now present, in relation to FIG. 2, a particular embodiment of the method according to the invention. It protects important information from bursts and provides solutions to the contradiction between optimizing a video stream containing bursts and smoothing the bursts for quality transport in the network.

In this particular embodiment of the method according to the invention, the overall mechanism forms a “multi-layer decentralized traffic conditioner” called “MLDTC” (for “Multi-Layers Decentralized Traffic Conditioner”). It consists of two functions executed sequentially:

- the first is called "MLTR" (for "Multi-Layers Traffic Regulator") because it forms a "multi-layer traffic regulator". It provides burst control by hierarchical level. It is based on the implementation of a token bucket with N operating levels (referenced 30), with

N buffers of virtual tokens. Each token buffer corresponds to a hierarchical level. Each operating level is defined by a set of parameters (see detailed discussion below). The MLTR function allocates tokens according to the priority of the incoming packet and the resource available in the corresponding token buffer. In the example in Figure 2, we have N = 3 and the representation of three buckets only indicates the distinction of the three sets of parameters

(there is actually only one bucket with three operating levels);

- the second is called “TBTS” (for “Token Bucket Traffic Shaper”) because it is based on a single-level token bucket algorithm (“Token Bucket”) (referenced 31) and performs a smoothing of the traffic for a regular flow on the network by limiting the instantaneous flow to a value acceptable by the network. The TBTS function buffer is of reasonable capacity to guarantee a lower cost of the systems and a limited transfer time in the supply of information to the user. The counterpart of the finite size is the limitation of the bursts accepted at the input of the network.

The MLTR function is adapted to the differentiated acceptance of bursts according to the priority level. It applies to IP packets (referenced 20 to 26 in Figure 2) whose DSCP (“Differentiated Services Code point”) field is marked either by the source or by a classification system. Each priority level i has its own parameters, for a single buffer, common to the 3 levels, but with varying levels of acceptance of data packets. This mechanism meets the expectations of a video signal, since it does not process all information uniformly. Indeed, it is recalled that an MPEG coding results in several levels of information which should be treated differently according to their importance. The objective is to favor the bursts of a level i compared to a level j, whose information is less important (j> i). The packets relating to level i then have priority to exploit the available resources.

Thanks to the TBTS function, the same average bit rate is obtained for different burst sizes, and taking into account the interval separating them. Such a mechanism is well suited to bursts of video streams, which are variable, due to the great diversity of content transported (sports, news, landscapes, ...).

An exemplary embodiment of the MLTR function is now presented in detail, which provides regulation and control of bursts. In the following description, we study by way of example the case where this MLTR function is based on a token bucket with three operating levels (N = 3).

As illustrated in FIG. 3, each operating level i of the token bucket with three operating levels 30 is managed by a regulator bj, bm _; ), i E {1, 2, 3}, with: - the nominal flow of this regulator;

- bm _j the maximum size of the token buffer for this regulator;

- b _j (t) the instantaneous value of filling the token buffer of this regulator. The size of the token buffer (b imposes a maximum size for bursts for each level. The tolerance of a level regulator vis-à-vis large bursts depends on the size of the token buffer b _; and the debit .

Compliant packets (i.e. those to which it has been possible to allocate tokens by the multi-level bucket 30) are placed in a buffer of packets to be sent 28, which forms a means of managing a queue wait. If an insufficient number of tokens is available in the multi-level bucket, the packets are then considered as non-compliant and are discarded. They are thrown in the trash referenced 27. Another option is to transmit these packets with a lower priority. However, re-marking packets to give them a lower priority increases the probability of packet rejection in congested nodes.

To favor the bursts of the highest priority levels, the three token buffers, bl, b2 and b3 are shared between the different levels. In other words, a packet of priority level i can be allocated tokens from a token buffer associated with a priority level j of lower priority (j> i) when the tokens available in the buffer of level tokens of priority i are not sufficient.

However, because of this borrowing principle, packets of level i risk using all the token resources of lower priority levels j. This can prevent guaranteeing the nominal flow at level j in favor of level i. As illustrated in FIG. 3, the solution is to limit this borrowing by a parameter K _j , specific to level j, the objective of which is to protect the latter from higher priority levels by guaranteeing a quantity of resources (tokens) reserved exclusively for packets of level j. Consequently, the parameter K _j guarantees a threshold for filling the token buffers below which packets of a higher priority level can no longer be used. The parameter K _j of the level regulator j is illustrated in Figure 3.

The value of K _j must be chosen such that bmj> K _j > MTU.

This amounts to guaranteeing for packets of level j the nominal bit rate and bursts limited by K _j . The particular case where K _j is adapted to the useful size of a packet on the network (MTU (“Maximum Transfer Unit”, ie “maximum size of an elementary transfer unit”) for a network IP) corresponds to a guarantee of the nominal flow rate r _j for level j but without guarantee of gusts. Token resources could be used by higher priority levels.

The three sets of parameters defining the three operating levels of the multi-level token bucket can be described:

- either by a representation of three independent buffers, with a shared use of resources between the three levels;

- or by a cumulative representation of resources, making it easier to highlight the priorities between the levels and the interdependencies of operation stemming from the sharing of resources.

However, these representations are identical in their operation. We now present, in relation to FIG. 4, a description of the operation of the multi-level token bucket with independent buffers. The reloading of token buffers is calculated for each of the three levels when a new packet arrives, as a function of the time separating it from the previous packet.

(Equation 1) The incoming packet of level i and size P is taken into account by the following algorithm: (packet mode)

(Equation 2)

FIG. 4 is a graphic representation of this token allocation algorithm in the case where the operation of the multi-level token bucket is described with independent buffers. It shows the possible use of the resources b _t , b ₂ and b ₃ for each of the levels. The thick lines (referenced 41, 42 and 43) show the filling of the token buffers (that is to say the number of tokens available) for each level, and the arrows the resources (that is to say tokens) taken by incoming packets (PI, P2 or P3) according to their priority.

We now present, in relation to FIG. 5, a description of the operation of the multi-level token bucket with correlated buffers.

Operation with three independent regulators i G {1, 2, 3}, is equivalent to operation with three dependent regulators B _i R _i , BM _i ) with:

- Biψ) the instantaneous value of the filling of the virtual token buffer relating to the packets of level i;

- BM _j the maximum size of the virtual token buffer relating to level i packets.

The sizes of token buffers per level are obtained by: (Equation 3)

This mode implies that: Bl ≥ B2 ≥ B3

The reloading of token buffers can then be expressed in a form equivalent to Equation 1 by:

B _x (t + B ₂ (t + T) = min [(b ₂ (t) + min [(b ₃ (t) + B ₃ (t + T) = min [(& ₃ (t) + r ₃ 1) bm ₃ ]

(Equation 4)

If we assume that min [(ô ₁ (t) + r, .T ') bm _i .] = B, (t) + r. , (Equation 4) becomes

B _x {t + T) = b _x (t) + b ₂ (t) + b ₃ (t) + (r _x + r ₂ + r ₃ ) l B ₂ (t + τ) = b ₂ (ή ₊ b ₃ (t) + (r ₂ + r ₃ ) TB ₃ (t + T) ≈ b ₃ (t) + r ₃ .T

FIG. 5 is a graphic representation of the token allocation algorithm in the case where the operation of the multi-level token bucket is described with correlated buffers. It shows the possible use of resources B ,, B ₂ and B ₃ for each of the levels. As in Figure 4, the thick lines (referenced 51, 52 and 53) show the filling of the token buffers (that is to say the number of tokens available) for each level, and the arrows the resources (i.e. tokens) taken by incoming packets (PI, P2 or P3) according to their priority.

If the reloading equations translate exactly the same behavior for the two approaches, the choice of the allocation of tokens to packets on arrival can be achieved by two alternatives:

- in batch mode (packets): a packet can only use one regulator;

- in continuous mode (bits): a packet can use several regulators at the same time. According to the operation in discontinuous mode (packets), the taking into account of the arrival of the packet is obtained by the following algorithm:

Note that (Equation 2) and (Equation 5) are equivalent.

In this discontinuous operating mode (packets), a packet is served by the resources of the level corresponding to the packet (level i) or of a lower priority level (level j). It should be noted that this operation is not optimal, since an incoming packet is rejected even if the sum of the available resources distributed over the 3 levels is sufficient.

According to the operation in continuous mode (bits), the taking into account of the arrival of the packet is obtained by the following algorithm: shipment;

A priori this continuous operating mode (bits) is more optimal than the discontinuous mode (packets). Indeed, it allows maximum use of own resources of the level before requesting resources at a lower priority level.

We now present in detail an embodiment of the SELV function which provides traffic shaping.

The single-level token bucket 31, on which this SELV function is based, is for example defined by the following parameters:

- R, the average flow;

- R _max , the maximum flow at the outlet;

- B (t), the instantaneous value of filling the token buffer (B _max is the maximum size of the token buffer);

- S, the instantaneous value of filling the packet buffer 28 (S _max is the maximum size of the packet buffer 28); - T, the time between the arrival of two consecutive packets;

- τ, the duration of a burst of packets.

Compliant packets (i.e. those to which it was possible to allocate tokens by the single-level bucket 31) are transmitted while non-compliant packets are delayed in the packet buffer 28 to contain them in the targeted traffic envelope. The size of the packet buffer 28 should be handled with care because it can induce an additional delay, which must remain reasonable.

The operation of the single-level bucket 31 (and therefore of the SELV function) can be described by the following equations:

B (t ₊ τ) = min [(B (t) + R.τ) B _m

L.ï ≤ L, + ϋ.τ → τ ≤ - ^5raax

Taking account of the P package _; is obtained by the following algorithm:

If we consider r _max , the maximum bit rate at the output of the MLTR function, the evolution of the filling of the packet buffer 28 between the arrival of two consecutive packets can be described by the following equation:

S (t + τ) ≤ S (t) -B _{mm +} (r _msx -R) T

and S (t) -RT-B _mm ≤ S (t ₊ τ) ≤ S {t) ₊ (r _max -R) τ

Claims

1. Method for controlling a traffic of data packets entering a network, the traffic comprising N streams and / or substreams each associated with a priority level, N> 2, each of the packets being marked with the priority level associated with the stream or substream to which said packet belongs, characterized in that it comprises a step of implementing a token bucket mechanism with N operating levels with N token buffer memories each containing a number of tokens available, the tokens of each of the N token buffer memories being used to process one of the N priority levels, each of the packets being accepted or refused according to whether it is possible to allocate tokens or not according to the tokens available at least in the token buffer memory used to process the priority level of said packet.

2. Method according to claim 1, characterized in that the traffic comprises N sub-flows each corresponding to one of the N hierarchical levels of a hierarchical flow or of an aggregate of hierarchical flows.

3. Method according to claim 1, characterized in that the traffic comprises N sub-streams each corresponding to one of the N types of images of a multimedia stream or of an aggregate of multimedia streams.

4. Method according to claim 1, characterized in that the traffic comprises N streams each corresponding to one of the streams of a multiplex of at least two streams.

5. Method according to any one of claims 1 to 4, characterized in that the traffic comprises N streams and / or sub-streams belonging to the same class of service.

6. Method according to any one of claims 1 to 5, characterized in that the refused packets are discarded.

7. Method according to any one of claims 1 to 6, characterized in that the network is of IP type or equivalent.

8. Method according to any one of claims 1 to 7, characterized in that each of the N operating levels of the token bucket mechanism is managed by a regulator bj η, bπij), i E {1 to N}, with : - r-, the nominal flow rate of the regulator; birii the maximum size of the regulator token buffer; bj (t) the instantaneous filling value of the token buffer of the regulator.

9. Method according to any one of claims 1 to 8, characterized in that the tokens of the N token buffer memories are shared between the N priority levels, a packet of priority level i being able to be allocated tokens d a token buffer associated with a lower priority level j when the tokens available in the token buffer of priority level i are not sufficient.

10. Method according to claim 9, characterized in that, for each priority level apart from the highest priority level, a quantity of tokens is guaranteed

(K _j ) reserved exclusively for packets having said priority level.

11. Method according to any one of claims 9 and 10, characterized in that the allocation of tokens to a packet of priority level i is carried out in a discontinuous mode per packet and consists in assigning: - either tokens available in the priority level token buffer i; or tokens available in a token buffer of priority level j with lower priority, when the tokens available in the buffer of tokens of priority level i are not sufficient.

12. Method according to any one of claims 9 and 10, characterized in that the allocation of tokens to a packet of priority level i is carried out in a continuous mode per bit and consists in allocating: tokens available in the memory -priority level i token buffer; and in addition to the tokens available in at least one buffer of tokens of priority level j with lower priority, when the tokens available in the buffer of tokens of priority level i are not sufficient.

13. Method according to any one of claims 1 to 12, characterized in that the packets accepted by the token bucket mechanism with N operating levels are placed in a queue, and in that said method comprises in in addition to a step of implementing a token bucket mechanism at a single operating level with a single token buffer, so as to take the packets contained in the queue and send them over the network by performing traffic smoothing by limiting the instantaneous speed to a value acceptable by the network.

14. Computer program, characterized in that it comprises program code instructions for the execution of the steps of the method according to any one of claims 1 to 3, when said program is executed on a computer.

15. Device for controlling data packet traffic entering a network, the traffic comprising N streams and / or substreams each associated with a priority level, N> 2, each of the packets being marked with the priority level associated with the stream or sub-stream to which said packet belongs, characterized in that it comprises means for implementing a token bucket mechanism with N operating levels with N token buffer memories each containing a number of tokens available, the tokens of each of the N token buffer memories being used to process one of the N priority levels, each of the packets being accepted or refused according to whether it is possible to allocate tokens or not according to the tokens available at least in the token buffer memory used to process the priority level of said packet.

16. Device according to claim 15, characterized in that it comprises means for sharing the tokens of the N token buffer memories between the N priority levels, a packet of priority level i being able to be allocated tokens of a token buffer associated with a lower priority level j when the tokens available in the token buffer of priority level i are not sufficient.

17. Device according to claim 16, characterized in that, for each priority level apart from the highest priority level, said sharing means comprise means for guaranteeing a quantity of tokens (K,) reserved exclusively for packets having said priority level.

18. Network equipment comprising a control device according to any one of claims 15 to 17, characterized in that said network equipment belongs to the group comprising: network equipment located between a network of an application or service provider and a network of a network service provider, constituting said network at the input of which data packet traffic control is carried out; routers included in nodes of a network of a network service provider, constituting said network at the input of which is carried out the control of data packet traffic.