Method for managing data traffic between a source entity and a recipient entity, and corresponding entity and computer program

Abstract

The invention relates to a method for managing data traffic between a source entity and a recipient entity, and to a corresponding entity and computer program. The invention relates to a method for managing data traffic between a source entity (11) and a recipient entity (12), implementing the following steps: selecting (13), for the source entity and the recipient entity, at least one policy for scheduling application data packets exchanged between the source entity and the recipient entity, taking into account at least one characteristic of an application associated with the application data; and establishing (14) at least one connection between the source entity and the recipient entity, on which the at least one selected packet scheduling policy is implemented.

Description

[0001] DESCRIPTION

[0002] TITLE: Method for managing data traffic between a source entity and a destination entity, corresponding entity and computer program.

[0003] 1. Field of the invention

[0004] The field of the invention is that of communications within a network, for example a computer network implementing the IP protocol such as a WAN network (for “Wide Area Network” in English).

[0005] More specifically, the invention proposes a solution for improving the exchange of data between a source entity and a destination entity connected to said network.

[0006] The invention finds in particular, but not exclusively, an application in a network based on an SD-WAN architecture (in English “Software-Defined Wide Area Network”).

[0007] 2. Prior art

[0008] A WAN can be used to interconnect the different sites of a company, each site hosting at least one local area network (LAN). Traditionally, such a WAN is based on the use of the MPLS protocol (Multi Protocol Label Switching), which supports communications established between the different sites and allows, for example, access to local applications hosted on a company server from one or other of the remote sites.

[0009] Congestion can occur in the WAN depending on usage, user behavior, or the nature of the applications or content that users wish to access. These applications or content may be hosted in cloud infrastructures.

[0010] New techniques for automating network resource production and operation procedures have recently been introduced. In particular, Software-Defined Networks (SDN) architectures have been deployed, in which a computational logic, typically centralized (e.g., an SDN controller), is responsible for the dynamic allocation of resources involved in routing traffic or in providing the communication service(s) supported by the network. These automation techniques allow, in particular, to significantly improve the flexibility of resource usage and their adaptability to user needs.

[0011] Such flexibility thus facilitates the allocation of network resources on demand, manages a company's application flows or even preserves the continuity of a communication service in the event of a transmission resource failure, for example. Communication services such as virtual private network (VPN) services can be deployed on SD-WAN infrastructures that facilitate the establishment of IPsec tunnels between company sites interconnected through the VPN, for example.

[0012] Similarly, SD-WAN architectures allow for easier management of a company's application flows, some of whose resources may be hosted in private, public or hybrid cloud infrastructures.

[0013] However, the management of traffic to or from a company site is often conditioned by changes in network access conditions, the availability of one or more network access paths, changes in traffic volume over time, pricing conditions for access to the network(s) or establishment of data transport facilities, the confidentiality of information exchanged between sites, etc.

[0014] However, such parameters are not always known to the calculation logic used by the SD-WAN infrastructure operator, which can lead to non-optimized engineering for routing data traffic.

[0015] Solutions have thus been proposed for so-called predictive management of quality of experience. These solutions are based on the use of artificial intelligence (AI) techniques such as machine learning and generally involve entities external to a network, such as an SDN controller.

[0016] However, these solutions require the exchange of large volumes of telemetry data, which could be used for malicious purposes. Furthermore, due to the use of external entities in particular, data aggregation and centralization also present security flaws that could be exploited for hacking or profiling purposes. These engineering approaches therefore present security and confidentiality issues.

[0017] There is therefore a need for a new data traffic management technique, which can in particular be applied to the management of traffic routed over an SD-WAN infrastructure, and which makes it possible to overcome at least certain drawbacks of the prior art.

[0018] 3. Statement of the invention

[0019] The invention proposes a solution in the form of a method for managing data traffic between a source entity and a destination entity, implementing: the selection, for said source entity and said destination entity, of at least one scheduling policy for application data packets exchanged between said source entity and said destination entity, taking into account at least one characteristic of an application associated with said application data, said at least one selected packet scheduling policy being supported by said source entity and by said destination entity, the establishment of at least one connection between said source entity and said destination entity, on which said at least one selected packet scheduling policy is implemented.

[0020] Such a method for managing data traffic according to at least one embodiment of the invention thus makes it possible to take into account the nature of the applications or data flows exchanged between a source entity and a destination entity to choose the packet scheduling policy to be implemented for a given connection (called a reference connection) established between this source entity and this destination entity. This approach is different from the state of the art where the configuration of the packet scheduling policy is local to a device and cannot be negotiated per connection or at the scale of the network connecting the source entity and the destination entity.

[0021] Indeed, such applications may have specific characteristics, for example a type of application, constraints or needs in terms of quality of service or experience, or in terms of security (maximum transit time between two local networks each associated with a company site for example, packet loss rate, preservation of the confidentiality of information exchanged between certain sites, etc.). They may also have constraints or needs in terms of prices or consumption (price optimization per access, consumption monitoring, etc.).

[0022] Thus, taking into account at least one characteristic linked to an application makes it possible to select a packet scheduling policy adapted to the traffic profile characteristic of said application, and intended to optimize the routing of data characteristic of this application between the source entity and the destination entity.

[0023] It is noted that the proposed solution is also applicable to point-to-multipoint connections (for example in the case of a television program broadcasting service based on the multicast transmission mode), or multipoint-to-multipoint connections (for example in the case of a videoconferencing service). In this case, the reference connection can be established between at least one source entity and at least one destination entity.

[0024] According to a particular embodiment, packet scheduling policies local to each network are selected (and not a common policy applied to all traffic routed over a WAN type wide area network), which makes it possible to maintain a certain control over the routing of data and the routes selected to route them between the different sites. These local packet scheduling policies can thus find resonance in the engineering choices related to the establishment of inter-site transport resources.

[0025] For example, such packet scheduling policies belong to the group including: a path management policy, a congestion management policy, a packet reassembly policy, a packet reordering policy, etc.

[0026] It is noted that such a method according to the invention can be implemented indifferently by the source entity and / or by the recipient entity.

[0027] More generally, such a method is applicable to any communication network justifying the implementation of packet scheduling policies (intended to optimize packet routing) capable of taking into account the constraints or application needs mentioned above. In particular, such a method can be applied by a wide area network based on an SD-WAN architecture.

[0028] Such a traffic management method, enabling for example the improvement of the quality of user experience, is called SCHEMATICS (“Procedure for SCHEdule Management for Technically-advanced Infrastructures”) in the remainder of the description.

[0029] A data packet scheduling policy is subsequently called PSS (for "Packet Schedule SCHEMATICS").

[0030] In a particular embodiment, the source entity can transmit to the destination entity a list of at least one packet scheduling policy supported by said source entity.

[0031] In another embodiment (which may be combined with the particular embodiment above), the source entity receives, from the destination entity, a list of at least one packet scheduling policy supported by said destination entity.

[0032] The source entity and / or the destination entity can thus check whether they support at least one common packet scheduling policy. Both entities can also indicate a preference that can be taken into account for the selection of a scheduling policy for an ongoing connection.

[0033] For example, according to a particular embodiment, the source entity can check whether the destination entity supports a packet scheduling policy preferred by the source entity. If this is not the case, the source entity can check whether the destination entity supports at least one packet scheduling policy supported by the source entity. If this is not the case, the management method according to the invention cannot be implemented.

[0034] The source entity, resp. recipient, can thus store in a memory a table recording all the packet scheduling policies supported by the recipient entity, resp. source. This table is maintained by the source entity (resp. recipient).

[0035] Such lists can be transmitted using a transport layer protocol between the source and destination entities. For example, QUIC, TCP (with or without the MPTCP option) protocols can be used. These parameters can also be exchanged using a protocol such as GRE, GTP, IKE, etc.

[0036] If the QUIC protocol is used, a new QUIC frame is defined to include the PSS information. This new QUIC frame, called a PSS frame, can be sent by the source entity, using a secure connection between the source entity and the destination entity, to trigger the destination entity to send the list of PSS(s) supported by the destination entity.

[0037] In a particular embodiment, said source entity, resp. recipient, transmits a parameter signaling to the recipient entity, resp. source, that it is capable of implementing said at least one selected packet scheduling policy.

[0038] For example, such a parameter takes a first value to indicate that the entity transmitting this parameter (source entity or destination entity) supports the procedure for selecting at least one packet scheduling policy, and a second value to indicate that the entity transmitting this parameter (source entity or destination entity) does not support the procedure for selecting at least one packet scheduling policy.

[0039] Alternatively, the absence of such a parameter means that the procedure for selecting at least one packet scheduling policy is not supported by the entity that sent the message.

[0040] Such a parameter can be transmitted using a transport layer protocol between the source entity and the destination entity. The same protocol among those mentioned previously as examples and used to transmit the lists proposed above can be used.

[0041] If the QUIC protocol is used, such a parameter may be a QUIC transport parameter called here “Customized_PSS”, valued for example at “0x1” to indicate that the entity sending the QUIC PSS frame comprising such a parameter supports the method according to the invention. The “Customized_PSS” parameter may be valued for example at “0x0” to indicate that the entity sending the QUIC PSS frame does not support the method according to the invention.

[0042] In a particular embodiment, said connection comprises at least two sub-connections each associated with a distinct path between said source entity and said destination entity, and said source entity sends said application data on at least one of said sub-connections taking into account said at least one packet scheduling policy selected for said connection.

[0043] According to this particular embodiment, the establishment of sub-connections corresponding to the reference connection established between the source and destination entities, also called a multi-path connection, makes it possible to switch or redirect all or part of the traffic to one path or another, for example depending on the quality of service or quality of experience objectives set / observed for an application, or depending on the evolution of the application data routing conditions (degradation of transit time, etc.).

[0044] For example, depending on the selected packet scheduling policy, different procedures for processing application data packets can be implemented during connection establishment, allowing traffic to be sent on one and / or the other path.

[0045] In a particular embodiment, the data traffic management method comprises the reception, by the source entity and / or the destination entity, of at least one traffic classification information making it possible to associate at least one packet scheduling policy with a type of application.

[0046] Such classification information makes it possible in particular to associate an application, or more generally a type of application, with at least one packet scheduling policy which makes it possible to satisfy the needs and / or constraints of such a type of application (for example in terms of quality of service or experience). The step of selecting a packet scheduling policy may in particular take into account such classification information. An application may communicate via a dedicated transport API to facilitate the selection of a PSS policy to be implemented for the establishment of an underlying transport connection.

[0047] According to a particular characteristic, the mode of application of said at least one selected packet scheduling policy (i.e. the way of processing the application data packets, for example the configuration and management of queues) is updated periodically and / or according to a change in the routing conditions of the application data exchanged between said source entity and said destination entity.

[0048] In this way, it is possible to execute actions in accordance with the selected packet scheduling policy, for example to switch or redirect traffic to one path or another, or to mark certain application data packets, in particular according to the quality of service or quality of experience objectives set for the application in question. According to a first example of implementation, the source entity is a first device connected to a local network, and the destination entity is a second device connected to an external network. Alternatively, the source entity is a second device connected to an external network and the destination entity is a first device connected to a local network.

[0049] According to this first example, the proposed solution is directly implemented by the first device, for example a terminal, and the second device, for example a remote server.

[0050] According to a second exemplary implementation, the source entity is an access device, connected to a local network and to at least one external network, routing the application data from a first device connected to the local network, and the destination entity is a second device connected to at least one external network. Alternatively, the source entity is a second device connected to at least one external network and the destination entity is an access device, connected to a local network and to at least one external network, routing the application data to a first device connected to the local network. It is noted that the source entity and the destination entity may be connected to separate external networks.

[0051] According to this second example, the proposed solution is implemented by an access device (connected to the same network as the first device) and the second device, for example a remote server, another access device, another terminal, etc. This second example can in particular be implemented when the first device does not support the procedure for selecting at least one packet scheduling policy.

[0052] According to a third exemplary implementation, the source entity is an access device, connected to a local network and to at least one external network, routing the application data from a first device connected to said local network, and the destination entity is a hub, routing the application data to a second device connected to at least one external network. Alternatively, the source entity is a hub, routing the application data from a second device connected to at least one external network and the destination entity is an access device, connected to a local network and to at least one external network, routing the application data to a first device connected to said local network. Again, the source entity and the destination entity may be connected to separate external networks.

[0053] According to this third example, the proposed solution is implemented by an access device (connected to the same network as the first device, for example a terminal) and a concentrator in communication with a second device, for example a remote server, another terminal, etc. Such a concentrator makes it possible in particular to aggregate the sub-connections between the access device and the concentrator, and to terminate these sub-connections. This third example can in particular be implemented when neither the first device nor the second device supports the procedure for selecting at least one packet scheduling policy.

[0054] In yet another example, the proposed solution is implemented by a hub and a remote server.

[0055] In particular, if the access equipment maintains a long-term connection with a recipient entity, the steps of transmitting and / or receiving lists of PSSs, and subsequently selecting at least one PSS, can be implemented during a change of application, or regularly (for example every 24 hours), or taking into account a change in the conditions for routing the application data exchanged between the source entity and the recipient entity, etc.

[0056] According to a particular embodiment, the access equipment establishes at least two connections between said source entity and said destination entity, each implementing a distinct packet scheduling policy selected taking into account at least one characteristic of an application.

[0057] According to this particular embodiment, the access equipment can thus establish a connection for an application, with a single packet scheduling policy for the connection in question. Alternatively, the access equipment can establish a connection for several applications, with different packet scheduling policies for the connection in question. In other words, several distinct application flows can be routed according to the same connection between source and destination entities, while being subject to distinct scheduling policies.

[0058] In a particular embodiment, the access equipment receives information relating to at least one of said external networks from at least one other access equipment connected to the local network and having established a connection with the remote server or the concentrator.

[0059] In this way, the access equipment according to an embodiment of the invention can collect information characteristic of the traffic passing through the other access equipment. Such information can in particular be used by the access equipment according to an embodiment of the invention to influence the procedure (or mode) of application of the packet scheduling policy selected for the access equipment and the server - if the server supports the procedure of selecting at least one packet scheduling policy, or the concentrator - if the server does not support the procedure of selecting at least one packet scheduling policy.

[0060] For example, it is considered that the different access devices connected to the same local network can use a “point-to-multipoint” channel established for example according to a multicast transmission mode, to share between them the information relating to the different external networks. In another embodiment, the access device transmits to a controller information relating to at least one of said external networks, said controller receiving information relating to at least one of said external networks from at least one other access device connected to said local network and having established a connection with the remote server or the concentrator. In this way, a controller can collect information characteristic of the traffic passing through the other access devices.

[0061] For example, it is considered that the different access devices connected to the same local network establish a connection with the controller to share information relating to the different external networks. Such a controller is, for example, an SDN controller.

[0062] In a particular embodiment, the method according to the invention selects one of said access devices to route said application data from said first device, resp. to said first device, taking into account said information relating to at least one of said external networks.

[0063] Such a step can in particular be implemented by access equipment connected to the local network or by the controller, for example when several access equipments support the procedure for selecting at least one packet scheduling policy according to an embodiment of the invention.

[0064] In particular, the selection of one of said access devices also takes into account an identifier associated with said application data.

[0065] For example, an application identifier is associated with application data related to an application of a certain type, presenting specific constraints (e.g. low latency). Thus, for example, all application data identified by the same application identifier will pass through the same access equipment.

[0066] In other embodiments, the invention relates to a corresponding source and / or recipient entity.

[0067] Such a so-called source entity, resp. recipient, capable of communicating with a recipient entity, resp. source, comprises at least one processor configured to: select, for said source entity and said recipient entity, at least one policy for scheduling application data packets exchanged between said source entity and said recipient entity, taking into account at least one characteristic of an application associated with said application data, said at least one selected packet scheduling policy being supported by said source entity and by said recipient entity, establish at least one connection between said source entity and said recipient entity implementing said at least one selected packet scheduling policy.

[0068] Such an entity is particularly suitable for implementing the data traffic management method described above. The source entity, resp. recipient, may of course support the various characteristics relating to the method according to the invention, which may be combined or taken in isolation. Thus, the characteristics and advantages of the source entity, resp. recipient, are the same as those of the method according to at least one embodiment of the invention described above. Consequently, they are not detailed further.

[0069] An embodiment of the invention also aims to protect one or more computer programs comprising instructions adapted to the implementation of at least one step of the method according to at least one embodiment of the invention as described above, when this or these programs are executed by a processor, as well as at least one information medium readable by a computer comprising instructions of at least one computer program as mentioned above.

[0070] 4. List of figures

[0071] Other characteristics and advantages of the invention will appear more clearly on reading the following description of a particular embodiment, given as an illustrative and non-limiting example, and the appended drawings, among which: Figure 1 illustrates the main steps implemented by a source and / or recipient entity according to at least one embodiment of the invention; Figure 2 illustrates an example of a WAN network in which the invention can be implemented;Figure 3 illustrates an example of a point-to-multipoint channel established to share information between different access devices connected to the same local network, Figures 4A to 4B illustrate the selection of an access device as an exit point taking into account information transported in the channel of Figure 3, Figure 5 illustrates the selection of an access device as an exit point taking into account an application identifier, Figure 6 illustrates an example of a point-to-point channel established to share information between two access devices connected to the same local network, Figures 7A to 7B illustrate the selection of an access device as an exit point taking into account the information transported in the channel of Figure 6, Figure 8 presents the simplified structure of a source and / or destination entity according to a particular embodiment of the invention.;

[0072] 5. Description of an embodiment of the invention 5.1 General principle

[0073] The general principle of the invention is based on the implementation of a specific packet scheduling policy on a connection established between a source entity and a destination entity, called a reference connection. This scheduling policy is based on a data packet management and congestion control mechanism (similar to a "scheduler" in English). Such a packet scheduling policy is chosen taking into account an application generating application data traffic between the source entity and the destination entity.

[0074] It is noted that such application data represents the data exchanged between a client (for example a terminal, access equipment) and a remote server. The exchange of this application data is therefore based on the establishment of a specific connection, also called an “application” connection, which may be different from the reference connection according to the invention.

[0075] The proposed approach is based in particular on the use of a packet scheduling policy activated for a reference connection established between the source entity and the destination entity. Thanks to this approach, the packet scheduling policies are characteristic of the different applications that are the subject of a data exchange between the source and destination entities, which allows a level of granularity adapted to the variety of these applications and traffic profiles. This configuration is therefore not "global", i.e. it is not generic (i.e. regardless of the number and nature of the applications that motivate the data exchange between source and destination entities), nor systemic (i.e. the application of the scheduling policies is characteristic of the nature of these different applications, but also of the conditions of access to the networks and the evolution of these conditions).In other words, different packet scheduling policies can be dynamically negotiated and implemented for different reference connections established between entities connected to at least one network. In particular, different packet scheduling policies can be implemented for different applications generating traffic between the same source entity and the same destination entity, and which is routed along different routes that connect the source and destination entities.

[0076] If we consider the context of a WAN network interconnecting several local networks hosted in separate sites of a company for example, the proposed solution contributes to the optimization of the use of intra- and inter-site resources, so that the routing of traffic can reflect the dynamic implementation of packet scheduling policies in line with the characteristics of the different applications likely to generate intra- or inter-site traffic (in particular in line with the requirements in terms of quality of service and / or security of these applications).

[0077] According to at least one embodiment, the proposed solution contributes to improving the quality of experience as perceived by a user of a connectivity service. This solution makes it possible in particular to detect (and consequently anticipate) possible degradations in the quality of experience which could for example be caused by network failures (break or overload of communication links, overload of switching equipment, etc.). In addition, the proposed solution does not compromise the integrity of sensitive information and respects its confidentiality. Indeed, no information is shared with an external entity for the management of the quality of experience perceived by a user located in a given site.

[0078] Figure 1 illustrates the main steps implemented by a source entity 11 and / or a destination entity 12 according to at least one embodiment of the invention, for the management of data traffic between the source entity 11 and the destination entity 12.

[0079] Such a data traffic management technique implements a selection 13, for the source entity 11 and the destination entity 12, of at least one packet scheduling policy (denoted for example PSS for “Packet Scheduler SCHEMATICS”) of application data, exchanged between the source entity 11 and the destination entity 12, taking into account at least one characteristic of an application associated with the application data. For example, such a characteristic is of the maximum transit delay type, maximum packet loss rate, preservation of the confidentiality of the information exchanged, etc.

[0080] In particular, said at least one selected packet scheduling policy is supported by the source entity 11 and by the destination entity 12. For example, a prior step of verifying the capabilities of the source entity 11 and / or of the destination entity 12 may be implemented to determine the packet scheduling policy(ies) supported by the source entity 11 and by the destination entity 12.

[0081] The data traffic management technique according to the invention also implements the establishment 14 of at least one reference connection between the source entity 11 and the destination entity 12. Such a reference connection is in particular configured, established and operated to implement the selected packet scheduling policy(ies). The implementation of these policies can be carried out at the level of the layer responsible for establishing said reference connection (e.g. TCP, QUIC) or at other levels (e.g. queue management in network interface cards, IP path management).When scheduling policies are configured for a reference connection but their implementation is not (exclusively) the responsibility of the layer responsible for establishing said reference connection, the identifiers of these policies can be exposed via APIs dedicated to accessing the modules responsible for applying these policies.

[0082] For example, such a reference connection uses a transport layer protocol, such as the QUIC protocol, which improves the security of exchanges between the source entity and the destination entity. In other embodiments, the reference connection may rely on the use of another protocol (for example, TCP (with or without the MPTCP option), GRE, GTP, IKE).

[0083] As indicated previously, according to a first example, the source entity (resp. recipient) may be a first device, for example a terminal, connected to a local network, and the recipient entity (resp. source) may be a second device, connected to at least one external network, for example a remote server, a second terminal, etc. According to a second example, the source entity (resp. recipient) may be an access device, connected to a local network and to at least one external network, routing application data from (resp. to) a first device connected to the local network, and the recipient entity (resp. source) may be a second device connected to at least one external network, for example a remote server, a second terminal, etc. According to a third example, the source entity (resp.recipient) may be an access device, connected to a local network and to at least one external network, routing the application data from (resp. to) a first device connected to the local network, and the recipient (resp. source) entity may be a concentrator, routing the application data to (resp. from) a second device connected to at least one external network.

[0084] Subsequently, no assumption is made as to the nature of the entities involved (fixed terminals, mobile terminals, CPE (Customer Premises Equipment), STB (Set-Top Box or TV decoder), access point (hotspot for example), etc.), as to the architecture of at least one local network to which at least one of these entities is connected, as to the architecture of a wide area network that connects at least one local network to which at least one of these entities is connected (fixed or mobile infrastructure, public or private infrastructure, etc.), as to the nature of the network supporting communications established between local networks or communications established on the Internet, etc. For example, the local or wide area network may be a home network, a corporate network, a university campus network, an industrial network that connects the robots of a site or that interconnects several production sites, etc.Similarly, no assumption is made as to the nature of the application(s). IP connectivity may notably be provided via a wired network, or wirelessly (e.g. 5G, Beyond 5G (B5G), 6G), or both.

[0085] 5.2 Implementation example 5.2.1 Wide area network

[0086] A detailed example of implementation of the invention is presented below.

[0087] For example, we consider a WAN network as illustrated in FIG. 2 interconnecting at least one LAN network 21 (associated for example with a company site #i) and one or more external networks 221, 222, 22j, also called access networks.

[0088] One or more terminals, or hosts, H1, H2, H3 are connected to the LAN 21. One or more access devices, or “Customer Equipment”, CEI, CEk are also connected to the LAN 21. These access devices make it possible to connect the LAN 21 to at least one of the external networks 221, 222, 22j, to which a server S can be connected.

[0089] For example: one or more access devices can be used to connect a local network to the same external network: for example, the access devices CEI and CEk allow the local network 21 to be connected to the external network Net. #2 222, the same access device can be used to connect a local network to several access networks: for example, the access device CEI allows the local network 21 to be connected to the external networks Net. #1 221 and Net. #2 222, one or more access devices can be used to connect a local network to several access networks: for example, the access devices CEI and CEk allow the local network 21 to be connected to the external networks Net. #1 221, Net. #2 222 and Net. #j 22j.

[0090] Subsequently, the term "CE" is used to denote any equipment connected to a local network and which allows the said local network to be connected to at least one external (access) network. A CE can notably be a router, or equipment which simply routes traffic to or from the local network ("forwarder" in English).

[0091] A CE may in particular be placed under the operational responsibility of the local network administrator or that of an operator of one of the external networks, etc.

[0092] In a particular embodiment, at least one of the external networks 221, 222, 22j may be a wired access network, a cellular access network (5G, B5G, 6G, etc.), a transit network, etc.

[0093] In particular, external networks may provide global IP connectivity (allowing access to the Internet) or restricted connectivity (for example, to the sites of the same company, to access to resources hosted in private or public cloud infrastructures, etc.). Among these different accesses, one or more may be dedicated to connecting a single site (this is often the case for companies that wish to benefit from exclusive connectivity not shared with other entities). It should also be noted that these different accesses may be operated by the same operator or by separate operators.

[0094] If we consider a WAN network that connects several LAN networks hosted on separate sites of the same company, communications between the company sites can be of different types:

[0095] “any-to-any”: different sites can communicate with each other without any restrictions,

[0096] “hub-and-spoke”: so-called “Spoke” sites can communicate only with so-called “Hub” sites while “Hub” sites can communicate directly with each other,

[0097] “hub-spoke-disjoint”: This mode is similar to the “hub-and-spoke” mode except that the “hubs” cannot communicate with each other.

[0098] These engineering choices can be distorted depending on the nature of the traffic likely to be exchanged between sites, traffic prioritization policies, engineering of access to internal company resources when a user is traveling, etc.

[0099] The invention finds applications in particular in these different contexts.

[0100] In a particular embodiment, a CE can communicate via all or part of these different external networks with at least one network element, called a “network hub” or “hub”, via dedicated reference connections typically based on the establishment of tunnels.

[0101] No assumption is made as to the location of a hub.

[0102] For example, at least one concentrator 23 may be deployed in at least one of the external networks 221, 222, 22j.

[0103] For example, we consider that the first device is a terminal H1, which requires the execution of an application hosted by the server S. The application data exchanged between the terminal H1 and the server S are transported over an “application” connection between the terminal H1 and the server S, illustrated in dotted lines in Figure 2.

[0104] If the terminal H1 and the server S both support the procedure for selecting at least one packet scheduling policy according to the invention, then the distribution of traffic between the different external networks can be managed by the terminal H1 and / or the server S. A reference connection according to the invention can then be established between the terminal H1 and the server S. In this case, the application connection and the reference connection can be the same connection.

[0105] If the terminal H1 does not support the procedure for selecting at least one packet scheduling policy according to the invention but the server S supports such a procedure, then the distribution of the traffic can be managed by at least one access device CEI, CEk of the local network and / or the server S. A reference connection according to the invention can then be established between the access device and the server. Such a reference connection can in particular be associated with the application connection for routing the application data between the terminal and the server via the access device.

[0106] If neither the terminal H1 nor the server S supports the procedure for selecting at least one packet scheduling policy according to the invention, then the distribution of the traffic can be managed by at least one access device CEI, CEk of the local network and / or by at least one concentrator 23. A reference connection according to the invention can then be established between the access device and the concentrator. Such a reference connection can in particular be associated with the application connection for routing the application data between the client and the server via the access device and the concentrator.

[0107] An example of a reference connection 24 between the access equipment and the concentrator is notably illustrated in solid lines in Figure 2.

[0108] 5.2.2 Operation of access equipment and concentrator

[0109] For the sake of simplification, the following is considered in the context where neither the terminal H1 nor the server S supports the procedure for selecting at least one packet scheduling policy. The distribution of traffic between the different external networks is therefore managed and executed by at least one access device CEI, CEk of the local network and / or at least one concentrator 23, and the selected packet scheduling policy(ies) implemented on a reference connection between an access device and a concentrator, which therefore differs from the application connection established between the terminal H1 and the server S.

[0110] Note, however, that this is a simple example, and the steps described below for a CE can more generally be implemented by a source entity and the steps described below for a hub by a destination entity, for data traffic from the LAN to an external network. For data traffic from the external network to the LAN, the source entity can be a hub and the destination entity a CE.

[0111] According to the example considered, a CE can be configured with at least one information allowing to identify or reach at least one concentrator. Several concentrators can be declared to the same CE, for example by means of a static configuration or a dynamic configuration using a protocol like DHCP or CWMP or NETCONF, to provide the identification / reachability information of the concentrator(s).

[0112] In particular, if the network supporting inter-site communications is an SD-WAN network, i.e. a network whose resources are controlled and operated by a logically centralized computing intelligence, typically called an SDN controller, the concentrator can be an “SD-WAN GW” gateway (“SD-WAN Gateway” in English).

[0113] Information that identifies a hub includes, for example, one or more IP addresses (IPv4 and / or IPv6), one or more port numbers, and / or an authentication identifier, etc.

[0114] According to a first example, an authentication identifier may in particular be used to verify the authorization of a hub to establish a reference connection with a CE. This identifier may be verified when establishing a first reference connection between the CE and this hub. Such a connection is typically established using dedicated tunnels per available access path established between the CE and the hub.

[0115] According to a second example, the addresses and / or port numbers can in particular be used as destination addresses and / or port numbers of the reference connections to identify a hub.

[0116] As described above, a hub is configured in particular to be able to route data received from one CE to another CE, to (or from) a server located in a public or private cloud, or more generally, to (or from) a server connected to the Internet. In addition, a hub may maintain entries in a table, for example a BIB (Binding Information Base), the entries of which allow the hub to select the relevant CE to which the return traffic will be routed.

[0117] 5.2.3 Data Packet Scheduling Policy

[0118] As indicated above, in particular in relation to the general principle of the invention, at least one data packet scheduling policy (PSS) can be selected for a source entity / destination entity pair. Such a data packet scheduling policy can in particular support all or part of the following functions: management of available paths, congestion management, packet reassembly, packet reordering, etc.

[0119] A PSS may possibly take into account other parameters for the execution of the functions previously described, such as: pricing conditions, indicated for example in the contracts established with the operators of the various external networks, user instructions, for example minimization of the costs incurred, balancing of the use of paths, etc.), experience of the use (past, historical) of the resources associated with each external network, which makes it possible for example to qualify the stability of certain resources in use and to put in place appropriate maintenance policies.

[0120] An entity implementing the invention (for example a CE or a concentrator) may in particular take into account different parameters to select at least one PSS of application data exchanged between the source entity and the recipient entity, taking into account at least one characteristic of an application associated with the application data. For example, an entity implementing the invention may select at least one PSS making it possible to adapt the use of resources, and / or to optimize latency, and / or to maximize the use of resources, and / or to improve their availability, etc.

[0121] An entity implementing the invention (for example a CE or a concentrator) may in particular establish at least one reference connection between the source entity and the destination entity, on which the selected PSS is implemented. In certain embodiments, such a reference connection is based on at least two sub-connections each associated with a distinct path between the source entity and the destination entity. The choice of the sub-connection(s) used to route the application data may depend in particular on the mode of application of the selected PSS.

[0122] An entity implementing the invention (for example a CE or a hub) may in particular maintain information characteristic of at least one external network, which feeds for example a local function for monitoring and detecting symptoms characteristic of the deterioration of the quality of service or the quality of experience (QoE, "Quality of Experience") for a given application. Such a function is based for example on the exploitation of data which can be processed by artificial intelligence techniques such as machine learning and the use of specific learning algorithms (for example a reinforcement learning algorithm) and is executed locally (typically supported by a CE).Such a function allows for example to monitor: the queue filling rate: monitoring of the queues observed on each interface used by a CE to connect to an external network. The queue filling rate can inform a CE about the quality of transmission via the interface concerned.This information can be used to decide which interfaces to use to route data based on the quality of service or QoE needs of a given application, for example, a transit delay (“One-way transit delay”) as observed on a path, a round-trip time (RTT) as observed on a path, and in particular a path providing access to a hub, packet loss observed on a path, an inter-packet delay variation or jitter, advanced application parameters calculated by robots that emulate certain applications (for example, VoIP robots, Webex® robots), a history of congestion observed on a path, etc.

[0123] Monitoring the quality of service or QoE for a given application, for example, from the monitoring function allows in particular to update the application mode of the selected PSS. In other words, this different information can be used by a CE (resp. a hub) to execute several actions characteristic of the application of a PSS, depending on the quality of service or QoE constraints of the applications, for example. Such actions can consist of executing certain algorithms such as: "Round-robin" type algorithm: the paths (also called "links") are invoked cyclically depending on an exit point (CE, for traffic from the LAN to an external network), associated with each path.For example, the weight of each path can be set by an administrator or calculated (dynamically) based on several parameters (e.g. optimization of the costs of the reference connection), optimization of the storage time of packets in queues by means of time interval management, etc.

[0124] Priority-based: priorities are assigned to each path, for example by taking into account a PBR policy (Policy-Based Routing), an RTT threshold (RTT threshold): paths are used until a certain RTT threshold is reached. For example, the threshold is set so that the PSS application can guarantee that the paths used do not have an RTT that does not meet application expectations. The algorithm(s) involved (queue management algorithms, in particular) in the PSS application allows, in particular, proactive management of latency deterioration, priority assigned to paths with the lowest RTT (Lowest RTT first): such paths are, for example, preferred for routing traffic to a hub, etc.Different histograms and statistical distributions can also be maintained for proactive management of quality of service and QoE parameters. Traffic can then be distributed between different paths according to a QoE objective for example, and not only according to the QoE observed at a given time. For example, a CE can: replicate a part of the data packets (expressed for example as a percentage of the total traffic) between several paths for a given period, switch all or part of the traffic to one or more source entities according to the observation of the queue filling rate, the evolution of the RTT parameter, or according to other criteria or symptoms observed by the source entity.

[0125] In a particular embodiment, a PSS data packet scheduling policy may be identified by a unique identifier. For example, a PSS may be identified by an integer, a name, etc. The PSSs by source entity / destination entity “pair” may in particular be referenced in a register (for example PSS1 between a given CE and a given concentrator, PSS2 between a given concentrator and a given server, PSS3 between a given terminal and a given server).

[0126] 5.2.4 Selection and implementation of a data packet scheduling policy

[0127] We return to Figure 2 and the example in which neither terminal H1 nor server S supports the procedure for selecting at least one packet scheduling policy.

[0128] When establishing a first reference connection from a CE to a hub, the CE (e.g. the CEI) checks whether the hub 23 supports the procedure for selecting at least one packet scheduling policy according to the invention. Alternatively, the CE may use a dedicated connection to check whether the hub supports said procedure. This connection is then closed and is therefore not used to transport application data.

[0129] For example, a first reference connection using a transport layer protocol, for example QUIC, is established between the IEC and the hub 23.

[0130] According to a particular embodiment, the CE can use a new QUIC transport parameter called here “Customized_PSS”, to signal that the entity issuing the parameter (CEI or concentrator 23 for example) supports the procedure for selecting at least one packet scheduling policy.

[0131] For example, a “Customized_PSS” parameter valued at “0x1” indicates that the procedure for selecting at least one packet scheduling policy is supported by the entity issuing the parameter, and a “Customized_PSS” parameter valued at “0x0” (or the absence of such a parameter) of transport indicates that the procedure for selecting at least one packet scheduling policy is not supported by the issuing entity (IEC or concentrator 23 for example).

[0132] If the source entity (CEI for example) receives the “Customized_PSS” parameter set to “0x1” from the destination entity (concentrator 23 for example), the source entity can send to the destination entity a list of the packet scheduling policy(ies) supported by the source entity.

[0133] If the QUIC protocol is used on the first connection (dedicated or reference) established between the source entity and the destination entity, the source entity can use a new QUIC frame, here called QUIC PSS frame, to inform the destination entity of the packet scheduling policy(ies) supported by the source entity. The destination entity can keep in memory the list of PSSs supported by the source entity, in particular for the management of return traffic.

[0134] The recipient entity may send to the source entity a list of the packet scheduling policy(ies) supported by the recipient entity (in particular if the source entity has not communicated to the recipient entity the PSSs supported by the source entity), or a selection of the packet scheduling policies supported by the source entity and the recipient entity.

[0135] For example, the source entity receives a list of PSSs supported by the destination entity in a QUIC PSS frame: PSS#1, ..., PSS#i.

[0136] The source entity can notably keep in memory the list of PSS supported by the recipient entity.

[0137] For example, the transmission from the recipient entity to the source entity of the list of PSSs supported by the recipient entity can be implemented regularly, for example every 24 hours, to refresh the list of PSSs stored in a memory of the source entity.

[0138] It is subsequently assumed that at least one common PSS is supported by the source entity and the recipient entity. It is also assumed that the source entity and the recipient entity also support at least one of the same PSS application modes.

[0139] Among the PSSs supported by the source entity and the destination entity, at least one PSS is selected taking into account the characteristics of an application associated with the application data exchanged between the source entity and the destination entity. Such characteristics may include in particular constraints of the application in question.

[0140] At least one reference connection, on which at least one selected PSS is implemented, is established between the source entity and the destination entity (for example when starting or restarting the source entity, or when establishing the communication characteristic of the application used - for example when establishing an HTTP (application) connection from a terminal connected to the local network in which one or more CEs according to the invention are deployed, also called application connection).

[0141] Such a reference connection is based, for example, on the QUIC protocol.

[0142] In one embodiment, the selection of at least one PSS is performed prior to establishing the reference connection. For example, the source entity selects a PSS to be activated for the reference connection (associated with an application or a group of applications of the same type) and communicates the PSS identifier to the destination entity. The source entity and the destination entity then activate the same PSS for this reference connection. In another embodiment, the selection of at least one PSS is performed simultaneously with establishing the reference connection. It is noted that the application of the same PSS can be performed for one or more reference connections established between the source entity and the destination entity.

[0143] In particular, the reference connection is accepted by the recipient entity if the PSS is supported by the recipient entity. This capacity verification step (to support said PSS) is not required if the PSS negotiation is carried out beforehand between the source entity and the recipient entity, and not during the establishment of the reference connection. The reference connection establishment request is refused if the PSS indicated by the source entity is not supported by the recipient entity or if the "Customized_PSS" parameter set to "0x1" has not been exchanged between the source entity and the recipient entity.

[0144] The source entity, for example the CE, can in particular establish a reference connection comprising several sub-connections (also called multi-path connection) with the destination entity (for example the concentrator). As already indicated, the establishment of sub-connections makes it possible to switch / redirect traffic to one path or another, for example depending on the QoE objectives set by an application or depending on the evolution of the transmission conditions (degradation of the transit time for example).

[0145] To do this, for a reference connection for which at least one PSS has been selected, the source entity negotiates with the concentrator the PSS application mode to be implemented for the application flows transported on this reference connection. The negotiation is possibly carried out during the establishment of the communication characteristic of the application used between the terminal and the server, also called the application connection. The data packets transmitted on the reference connection are then distributed between the different paths according to the PSS application mode activated and according to the quality of service and QoE conditions observed by the source entity.

[0146] 5.2.5 Variants In a particular embodiment, traffic classification information may be provided to the source entity and / or the destination entity to associate an application type with a packet scheduling policy that would make it possible to satisfy, for example, the quality requirements related to this application type.

[0147] In other words, the source entity and / or the destination entity can associate an “application” connection (which transports the application data) with a reference connection on which a PSS is implemented, selected to satisfy the quality requirements linked to this type of application.

[0148] This classification information can be: configured by an administrator using a management interface specific to the source and / or destination entity, communicated via a signaling mechanism such as the PCP (“Port Control Protocol”) protocol: a PCP client can then be embedded in a terminal connected to the local network, exposed by an application server via a dedicated API: for example, the invocation of the API can be conditioned on an agreement between the server provider and the entity that manages the communication service (for example the operator of an SD-WAN network), indicated via a transport API, for example the API described in the RFC6897 document “Multipath TCP (MPTCP) Application Interface Considerations” of March 2013 or “QUIC API for Peer-to-peer Connections” of the W3C Community Group Draft report of March 3, 2022, etc.

[0149] Thus, the source entity can in particular select the mode of application of a PSS to be implemented to associate the received traffic with a pre-established reference connection, or decide to establish a new reference connection, taking into account at least one element belonging to the group comprising: traffic classification information, a PSS identifier, a heuristic local to the source entity, a change in the transmission conditions (for example degradation of the latency time observed on a reference connection or a sub-connection).

[0150] Traffic is then associated with an exit interface of the source entity and then routed over the associated subconnection(s).

[0151] Note that the source entity and the destination entity may use different paths to route forward and reverse traffic if the quality of service or QoE objectives are only satisfied in one direction of traffic routing (CE to hub or hub to CE), for example.

[0152] In particular, if no available path can satisfy the quality requirements of an application, the source entity can send an alert to the entity responsible for managing it, for example the SDN controller of the site where the source entity is deployed.

[0153] The case where the source entity is an access device and the destination entity is a concentrator (traffic from the LAN and destined for an external network) has been described above. Of course, the operations described above can be implemented in the case where the source entity is a concentrator and the destination entity is an access device (traffic from the external network and destined for the LAN). Similarly, the operations described above can be implemented by a first device such as a terminal if it supports a procedure for selecting at least one packet scheduling policy according to the invention, and / or a second device such as another terminal, a server, etc., if it supports a procedure for selecting at least one packet scheduling policy according to the invention.Thus, the source entity can be a terminal and the destination entity a server (or vice versa), the source entity can be an access device and the destination entity a server (or vice versa), the source entity can be a concentrator and the destination entity a server (or vice versa), the source entity can be an access device and the destination entity a concentrator (or vice versa).

[0154] 5.2.6 Plurality of access equipment

[0155] A particular embodiment is described below in which several access devices are connected to the same local network. In this case, it is possible to select one of the access devices as the exit point (or entry point) of the LAN.

[0156] The different CEs connected to the same local network may in particular use a dedicated channel to share information between them relating to the different external networks, for example information characteristic of the traffic passing through the CEs connected to the external networks. Such information may in particular be used to select one of the CEs connected to the local network to route application data between the terminal and the server.

[0157] According to a first example illustrated in Figure 3, the dedicated channel can be of the “point-to-multipoint” type. An access device CEI can thus receive information relating to at least one of the external networks from at least one other access device CE2, CE3, CEk connected to the local network and capable of establishing a reference connection with the remote server S or the concentrator 23. An example of implementation of this point-to-multipoint channel is based on a multicast transmission mode, where all the CEs subscribe to the same multicast group defined by a particular group address. This multicast address is declared in all the CEs having subscribed to the same multicast group, for example statically or dynamically using the resources of a protocol such as DHCP or CWMP or NETCONF.

[0158] The information received by a CE (for example CE2 in Figure 3) from other CEs (for example CEI) can thus feed into a path selection procedure implemented by the CE, to route the data received from terminals connected to the local network to one or more concentrators. Such information is for example characteristic of the different traffic passing through the different CEs, such as {source address; destination address} pairs.

[0159] Also, this information can be used by at least one CE to modify the routing in the local network for the application data traffic in accordance with the packet scheduling policy selected for the application associated with this application data. In particular, this information can be used by at least one CE to determine the egress point of the application data traffic according to different criteria such as the destination of the traffic sent by a terminal connected to the local network, the nature of the traffic sent by a terminal connected to the local network and whose constraints in terms of latency or variation of inter-packet delay may impose one path rather than another to reach a hub, etc.

[0160] For example, the selection of a CE will be conditioned by its ability to contribute to compliance with the level of quality of experience (QoE) characteristic of the nature of the service or application used by a terminal connected to the local network to reach a given destination. To do this, each of the CEs allowing said destination to be reached chooses a preferred path based on local conditions (access to the service or to a remote site, for example) likely to optimize the QoE as perceived by the user, and announces this path in the local network. The CE that contributes to providing optimal QoE will be selected to route traffic to a given destination. Note that the same procedure can be used for default paths (“wildcard”: “:: / 0” (IPv6) or “0.0.0.0 / 0” (IPv4)).

[0161] As an example, we consider an application connection established between the terminal H2 and the server S. Figures 4A and 4B illustrate a first path at a time T0 and a second path at a time T1 between the terminal H2 and the server S.

[0162] At time T0, illustrated in Figure 4A, the application connection is associated (for example by the CEI) with a reference connection established between the CEI and the concentrator 23. In other words, the application connection transporting the application data between the CEI and the concentrator 23 is associated with the reference connection established between the CE and the concentrator. The application data therefore transits via the CEI access equipment and the external network Net. #1. The different CEI and CEk access equipment can in particular observe the extended network (transit time, available bandwidth, traffic profile, etc.) and select an exit point (CE, for traffic from the LAN to an external network) according to the QoS parameters observed by the CEs and exchanged via the channels established between the CEs of the same site (Site #i).

[0163] At time T1, illustrated in Figure 4B, another exit point (CE) is selected. The application connection is then associated with a reference connection established between the CEk and the concentrator 23. The data then passes through the access equipment CEk and the external network Net. #j.

[0164] It is noted that in the event of traffic redirection to another exit point, the continuity of the application connection established between the terminal H2 and the server S can be preserved by the presence of the same concentrator 23 in the different sub-connections or paths taken by the data which transit through this same concentrator.

[0165] In a particular embodiment, the selection of a CE from among several CEs connected to the local network also takes into account an identifier associated with the application data exchanged between the terminal and the server.

[0166] According to a first example, such an identifier is an application identifier, for example “app-id”. The “app-id” identifier can in particular be used by a terminal for routing packets characteristic of specific applications, also called application data. For example, applications having the same QoE constraints can be identified by the same application identifier. For example, an application can communicate its identifier (“app-id”) via a local network API to indicate to a routing / forwarding process embedded in a CE the “application” route to use to route the data of this application within the local network. For example, the route advertisement messages contain an application identifier which makes it possible to maintain specific routes per application in the local network.In doing so, a LAN can then maintain differentiated routes per application, and thus, separate CEs can be chosen to route traffic to the same destination for a given application.

[0167] According to other examples, other identifiers may be used to select one route rather than another: for example, the same DSCP (DiffServ Code Point) coding may lead to the selection of routes for traffic marked EF (Expedited Forwarding) and other routes for traffic marked AF (Assured Forwarding), without prejudging the nature of the application(s) that will benefit from this differentiated treatment. In this case, a "dscp-val" identifier may be associated with the routes advertised between CEs in the messages exchanged between them via a dedicated channel.

[0168] As an example, Figure 5 illustrates the selection of an exit point (CEI or CEk, for traffic originating from the LAN and destined for an external network) according to the application (“app-id”) and the QoE parameters observed and exchanged between the CEs of the same site (Site #i). Separate routes are used to route the traffic according to the application constraints and the conditions observed by the different exit points (CEs) connected to the same local network. For example, a first route via the CEI access equipment is preferred for applications identified by the identifier app-id=l and a second route via the CEk access equipment is preferred for applications identified by the identifier app-id=2.

[0169] It is noted that in this embodiment implementing several CEs, in order to avoid contradictory instructions between different CEs of the same site (i.e. connected to the same local network), a CE must inform the other CEs before modifying the route.

[0170] A first example has been described above where the dedicated channel can be of the “point-to-multipoint” type.

[0171] Figure 6 illustrates a second example in which the channel dedicated to sharing information between CEs is a “point-to-point” channel.

[0172] According to this example, at least one access device connected to the local network and making it possible to establish a reference connection with the remote server S or the concentrator 23 transmits to a controller 61 information relating to at least one of the external networks to which it is connected. Such information can in particular be used to select one of the CEs connected to the local network to route application data between the terminal and the server.

[0173] An example of establishing such a point-to-point channel is to establish a (control) connection between a CE and one or more controllers operated by a company, for example.

[0174] Such a controller 61 (e.g., SDN controller) can be local to each site. In this way, it is possible to preserve the watertightness of communications between the different sites. Indeed, the decisions (routing policies, traffic redirection, management of the site's CEs, etc.) taken by such a controller are local to the site. In fact, these decisions do not interfere with those taken by the other controllers deployed on the other sites. Such engineering also makes it possible to not depend on the connectivity between the sites, which contributes to strengthening the robustness and the ability to apply the decisions taken by the controller, without inducing additional delay or compromising the correct application of the decisions, in particular when these must be taken in response to new quality of service or QoE conditions observed on the site in question.

[0175] Alternatively, a single controller can be used to manage multiple sites where multiple CEs are deployed. In this case, the controller can associate a CE with its deployment site. This information can be configured in the controller by an administrator or retrieved from each CE using a protocol such as NETCONF, for example.

[0176] Regardless of the engineering chosen (one controller per site or one controller for all sites), the controller uses the information received from the different CEs to decide on the local policy for selecting the exit point(s) within the local network to route traffic to a given destination, for all destinations or for a subset of destinations, taking into account several criteria such as quality of service or QoE conditions, the nature of the traffic, the different traffic profiles, traffic prioritization policies, etc.

[0177] As previously described in relation to Figure 5, the controller may in particular configure the CEs with routes specific to a group of applications having similar quality of service or QoE constraints. For example, the "app-id" identifier may be used to demultiplex the routes and be able to choose egress points (CEs, for traffic coming from the LAN and going to an external network) per application. The controller may also be responsible for establishing the channel(s) dedicated to sharing information between CEs: the exchange of information between CEs via such a point-to-point channel may also involve the controller itself, because the information collected may serve as input data for the computation of the routes (and the dynamic instantiation of the associated "application" routing policy) that will transit through such or such CE.

[0178] As an example, we consider an application connection established between the terminal H2 and the server S. Figures 7A and 7B illustrate a first path at a time T0 and a second path at a time T1 between the terminal H2 and the server S.

[0179] At time T0, illustrated in Figure 7A, the data passes through the access equipment CEI and the external network Net. #1. The application connection is associated with a reference connection established between the CEI and the concentrator 23. The controller 61 can in particular collect information from the different access equipment CEI and CEk and select an exit point (CE, for traffic from the LAN to an external network) according to the QoS parameters observed by the CEs of the same site (Site #i).

[0180] At time T1, illustrated in Figure 7B, another exit point (CE) is selected. The data then passes through the access equipment CEk and the external network Net. #j. The application connection is associated with a reference connection established between the CEk and the concentrator 23.

[0181] It is noted that in the event of traffic redirection to another exit point, the continuity of the application connection established between the terminal H2 and the server S can be preserved by the presence of the same concentrator 23 in the different sub-connections or different paths taken by the data which transits through this same concentrator.

[0182] According to a particular embodiment, the type of channel (point-to-point or point-to-multipoint) which allows information to be shared between CEs can be provided to the different CEs of the same local network or configured in the different CEs. If no such information is provided to a CE, then the communication procedure and the sharing of information between CEs is disabled by default.

[0183] 5.3 Corresponding entity

[0184] Finally, in relation to Figure 8, we present the simplified structure of a source and / or recipient entity according to one embodiment of the invention.

[0185] The source and / or destination entity, according to one embodiment of the invention, comprises a memory 81, a processing unit 82, equipped for example with a programmable computing machine or a dedicated computing machine, for example a processor P, and controlled by the computer program 83, implementing steps of the traffic management method according to at least one embodiment of the invention.

[0186] Upon initialization, the code instructions of the computer program 83 are for example loaded into a RAM memory before being executed by the processor of the processing unit 82.

[0187] The processor of the processing unit 82 implements steps of the traffic management method described previously, according to the instructions of the computer program 83, to: select, for said source entity and said destination entity, at least one policy for scheduling application data packets exchanged between said source entity and said destination entity, and taking into account at least one characteristic of an application associated with said application data, said at least one selected packet scheduling policy being supported by said source entity and by said destination entity, establish at least one connection between said source entity and said destination entity on which said at least one selected packet scheduling policy is implemented.

Claims

CLAIMS 1. Method for managing data traffic between a source entity (11) and a destination entity (12), implementing: • the selection (13), for said source entity and said destination entity, of at least one policy for scheduling application data packets exchanged between said source entity and said destination entity, taking into account at least one characteristic of an application associated with said application data, said at least one selected packet scheduling policy being supported by said source entity and by said destination entity, • establishing (14) at least one connection between said source entity and said destination entity, on which said at least one selected packet scheduling policy is implemented.

2. Method according to claim 1, characterized in that the source entity transmits to the destination entity a list of at least one packet scheduling policy supported by said source entity.

3. Method according to any one of claims 1 and 2, characterized in that the source entity receives, from the destination entity, a list of at least one packet scheduling policy supported by said destination entity.

4. Method according to any one of claims 1 to 3, characterized in that said source entity, resp. said destination entity, transmits a parameter signaling to the destination entity, resp. the source entity, that it is capable of implementing said at least one selected packet scheduling policy.

5. Method according to any one of claims 2 to 4, characterized in that said list according to claim 2 or claim 3 and / or said parameter according to claim 4 is transmitted using a transport layer protocol between said source entity and said destination entity.

6. Method according to any one of claims 1 to 5, characterized in that said connection comprises at least two sub-connections each associated with a distinct path between said source entity and said destination entity, and in that said source entity sends said application data on at least one of said sub-connections taking into account said at least one packet scheduling policy selected for said connection.

7. Method according to any one of claims 1 to 6, characterized in that it comprises the reception of at least one traffic classification information making it possible to associate at least one packet scheduling policy with a type of application.

8. Method according to any one of claims 1 to 7, characterized in that the mode of application of said at least one selected packet scheduling policy is updated periodically and / or as a function of a change in the conditions of routing of the application data exchanged between said source entity and said destination entity.

9. Method according to any one of claims 1 to 8, characterized in that said source entity, resp. destination entity, is a first device connected to a local network, and in that said destination entity, resp. source entity, is a second device connected to an external network.

10. Method according to any one of claims 1 to 8, characterized in that said source entity, resp. destination entity, is an access device, connected to a local network and to at least one external network, routing said application data from, resp. to, a first device connected to said local network, and in that said destination entity, resp. source entity, is a second device connected to one of said at least one external network.

11. Method according to any one of claims 1 to 8, characterized in that said source entity, resp. destination entity, is an access device, connected to a local network and to at least one external network, routing said application data from, resp. to, a first device connected to said local network, and in that said destination entity, resp. source, is a concentrator, routing said application data to, resp. from, a second device connected to one of said at least one external network.

12. Method according to any one of claims 10 and 11, characterized in that said access equipment establishes at least two connections between said source entity and said destination entity, each implementing a distinct packet scheduling policy selected taking into account at least one characteristic of an application.

13. Method according to any one of claims 10 to 12, characterized in that said access equipment receives information relating to at least one of said external networks, from at least one other access equipment connected to said local network and having established a connection with said second equipment according to claim 10 or said concentrator according to claim 11.

14. Method according to any one of claims 10 to 12, characterized in that said access equipment transmits to a controller information relating to at least one of said external networks, said controller receiving information relating to at least one of said external networks from at least one other access equipment connected to said local network and having established a connection with said second equipment according to claim 10 or said concentrator according to claim 11.

15. Method according to claim 13 or claim 14, characterized in that it selects one of said access equipments to route said application data from said first equipment, resp. to said first equipment, taking into account said information relating to at least one of said external networks.

16. Method according to claim 15, characterized in that said selection of one of said access devices also takes into account an identifier associated with said application data.

17. Entity called source (11), resp. recipient, capable of communicating with a recipient entity (12), resp. source, comprising at least one processor configured to: • select (13), for said source entity and said destination entity, at least one policy for scheduling application data packets exchanged between said source entity and said destination entity, taking into account at least one characteristic of an application associated with said application data, said at least one selected packet scheduling policy being supported by said source entity and by said destination entity, • establish (14) at least one connection between said source entity and said destination entity on which said at least one selected packet scheduling policy is implemented.

Images