Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L47/00—Traffic control in data switching networks
  • H04L47/10—Flow control; Congestion control
  • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
  • H04L47/2475—Traffic characterised by specific attributes, e.g. priority or QoS for supporting traffic characterised by the type of applications
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L47/00—Traffic control in data switching networks
  • H04L47/50—Queue scheduling

Definitions

• TITLE Method for managing data traffic between a source entity and a recipient entity, corresponding entity and computer program.
• 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).
• a network for example a computer network implementing the IP protocol such as a WAN network (for “Wide Area Network” in English).
• the invention proposes a solution for improving the exchange of data between a source entity and a recipient entity connected to said network.
• 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”).
• a WAN network can in particular be used to interconnect the different sites of a company, each site hosting at least one local network (in English LAN, for “Local Area Network”).
• a WAN network is based on the use of the MPLS protocol (in English “Multi Protocol Label Switching”, in French “multi protocol switching by labels”), which supports communications established between the different sites and allows for example the access to local applications hosted on a company server from one or other of the remote sites.
• Congestion phenomena can appear in the WAN network depending on uses, user behavior or even the nature of the applications or content to which users wish to access. These applications or content can be hosted in “cloud” infrastructures.
• SDN network architectures in English “Software-Defined Networks” have been deployed, in which a calculation logic, typically centralized (for example an SDN controller), is responsible for the dynamic allocation of the resources involved in the routing of traffic or in the provision of the communication service(s) supported by the network.
• Communication services such as virtual private network (VPN) services can in particular be deployed on SD-WAN infrastructures which facilitate the establishment of IPsec tunnels between the sites of a company interconnected to the through the VPN, for example.
• VPN virtual private network
• SD-WAN architectures allow easier management of a company's application flows, some of whose resources can be hosted in private, public or hybrid cloud infrastructures.
• the management of traffic to or from a company site is often conditioned by the evolution of network access conditions, the availability of one or more network access paths, the evolution of traffic volume over time, pricing conditions for access to network(s) or establishment of data transport facilities, confidentiality of information exchanged between sites, etc.
• 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 policy scheduling (“scheduling” in English) of 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 recipient entity, on which said at least one selected packet scheduling policy is implemented.
• Such a data traffic management method thus makes it possible to take into account the nature of the applications or data flows exchanged between a source entity and a recipient entity to choose the data traffic policy. scheduling of packets to be put in place for a given connection (called reference) 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 piece of equipment and cannot be negotiated per connection nor at the scale of the network connecting the source entity and the recipient entity.
• such applications may have particular 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 delay between two associated local networks each to 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 by access, consumption monitoring, etc.).
• 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.
• the proposed solution is also applicable to point-to-multipoint connections (for example in the case of a television program broadcasting service based on multicast transmission mode), or multipoint-to-multipoint connections (for example in the case of a videoconferencing service).
• the reference connection can be established between at least one source entity and at least one destination entity.
• packet scheduling policies local to each network are selected (and not a common policy applied to all traffic routed on an extended WAN type network), which makes it possible to maintain a certain control of the routing of data and the routes selected to transport it between the different sites.
• These local packet scheduling policies can thus find resonance in the engineering choices linked to the establishment of inter-site transport resources.
• packet scheduling policies belong to the group comprising: a policy for managing available paths (“Path management”, in English), a policy for managing congestion (“Congestion management”, in English), a packet reassembly policy (“Packet reassembly”, in English), a packet reordering policy (“Packet reordering”, in English), etc.
• such a method is applicable to any communication network justifying the implementation of packet scheduling policies (intended to optimize the routing of packets) capable of taking into account the constraints or application needs mentioned above.
• packet scheduling policies intended to optimize the routing of packets
• such a method can be applied by an extended network based on an SD-WAN architecture.
• SCHEMATICS Service for SCHEdule Management for Technically-advanced Infrastructures
• PSS Packet Schedule SCHEMATICS
• the source entity can transmit to the recipient entity a list of at least one packet scheduling policy supported by said source entity.
• the source entity receives, from the destination entity, a list of at least one packet scheduling policy supported by said recipient entity.
• the source entity and/or the destination entity can thus check whether they support at least one common packet scheduling policy. Both entities may also indicate a preference that may be taken into account when selecting a scheduling policy for a current connection.
• the source entity can check whether the destination entity supports a packet scheduling policy favored by the source entity. If this is not the case, the source entity can check if the destination entity supports at least one policy packet scheduling supported by the source entity. If this is not the case, the management method according to the invention cannot be implemented.
• 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).
• Such lists can in particular be transmitted using a transport layer protocol between the source entity and the recipient entity.
• a transport layer protocol between the source entity and the recipient entity.
• the QUIC, TCP protocols (with or without the MPTCP option) can be used.
• These parameters can also be exchanged using a protocol such as GRE, GTP, IKE, etc.
• PSS frame can be sent by the source entity, using a secure connection between the source entity and the recipient entity, to trigger the sending by the recipient entity of the list of the or PSS supported by the recipient entity.
• 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.
• such a parameter takes a first value to indicate that the entity which transmits this parameter (source entity or recipient entity) supports the procedure for selecting at least one packet scheduling policy, and a second value to indicate that the entity which transmits this parameter (source entity or recipient entity) does not support the procedure for selecting at least one packet scheduling policy.
• 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.
• Such a parameter can in particular be transmitted using a transport layer protocol between the source entity and the destination entity.
• 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.
• such a parameter can be a QUIC transport parameter called here "Customized_PSS", valued for example at "0x1" to indicate that the entity transmitting the QUIC PSS frame comprising such a parameter supports the method according to the invention.
• the “Customized_PSS” parameter can be set for example to “0x0” to indicate that the entity transmitting the QUIC PSS frame does not support the method according to the invention.
• said connection comprises at least two sub-connections each associated with a distinct path between said source entity and said recipient entity, and said source entity sends said application data over at least one of said sub-connections taking into account said at least one packet scheduling policy selected for said connection.
• the establishment of sub-connections corresponding to the reference connection established between the source and recipient entities makes it possible to switch or redirect all or part of the traffic towards a 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 application data routing conditions (degradation of transit time, etc. .).
• the data traffic management method comprises the reception, by the source entity and/or the recipient entity, of at least one piece of traffic classification information making it possible to associate at least one policy of packet scheduling to a type of application.
• 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 can 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 implement for establishing an underlying transport connection.
• the mode of application of said at least one selected packet scheduling policy (that is to say the way of processing the application data packets, for example the configuration and management of data queues). waiting) is updated periodically and/or according to an evolution of the routing conditions of the application data exchanged between said source entity and said recipient entity.
• the source entity is a first piece of equipment connected to a local network
• the destination entity is a second piece of equipment connected to an external network.
• the source entity is a second piece of equipment connected to an external network and the destination entity is a first piece of equipment connected to a local network.
• the proposed solution is directly implemented by the first equipment, for example a terminal, and the second equipment, for example a remote server.
• the source entity is access equipment, connected to a local network and to at least one external network, routing application data coming from a first equipment connected to the local network
• the recipient entity is a second piece of equipment connected to at least one external network.
• the source entity is a second piece of equipment connected to at least one external network
• the recipient entity is access equipment, connected to a local network and to at least one external network, routing the application data to a first equipment connected to the local network.
• the source entity and the destination entity can be connected to distinct external networks.
• the proposed solution is implemented by access equipment (connected to the same network as the first equipment) and the second equipment, for example a remote server, another access equipment, another terminal, etc.
• This second example can in particular be implemented when the first equipment does not support the procedure for selecting at least one packet scheduling policy.
• the source entity is access equipment, connected to a local network and to at least one external network, routing application data coming from a first equipment connected to said local network, and the recipient entity is a hub, routing the application data to a second piece of equipment connected to at least one external network.
• the source entity is a concentrator, routing the application data coming from a second piece of equipment connected to at least one external network and the destination entity is access equipment, connected to a local network and to at least one an external network, routing the application data to a first piece of equipment connected to said local network.
• the source entity and the destination entity may be connected to separate external networks.
• the proposed solution is implemented by access equipment (connected to the same network as the first equipment, for example a terminal) and a concentrator in communication with a second equipment, for example a remote server, a other terminal, etc.
• a concentrator makes it possible in particular to aggregate the sub-connections between the access equipment and the concentrator, and to terminate these sub-connections.
• This third example can in particular be implemented when neither the first equipment nor the second equipment supports the procedure for selecting at least one packet scheduling policy.
• the proposed solution is implemented by a hub and a remote server.
• the steps of transmitting and/or receiving PSS lists, and subsequently selecting at least one PSS can be implemented. implemented during a change of application, or on a regular basis (for example every 24 hours), or taking into account a change in the conditions of routing of application data exchanged between the source entity and the recipient entity, etc.
• 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.
• the access equipment can thus establish a connection for an application, with a single packet scheduling policy for the connection considered.
• the access equipment can establish a connection for several applications, with different packet scheduling policies for the connection considered.
• several distinct application flows can be routed along the same connection between source and recipient entities, while being subject to distinct scheduling policies.
• the access equipment receives information relating to at least one of said external networks coming from at least one other access equipment connected to the local network and having established a connection with the remote server or the concentrator.
• the access equipment according to one 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 one embodiment of the invention to influence the procedure (or mode) of application of the packet scheduling policy selected for the access equipment. access and the server - if the server supports the procedure for selecting at least one packet scheduling policy, or the hub - if the server does not support the procedure for selecting at least one packet scheduling policy .
• the different access equipment connected to the same local network can exploit a “point-to-multipoint” channel established for example according to a multicast transmission mode, to share between them information relating to the different external networks.
• the 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 coming from at least one other equipment access device connected to said local network and having established a connection with the remote server or the hub. In this way, a controller can collect information characteristic of the traffic passing through other access equipment.
• the different access equipment connected to the same local network establishes a connection with the controller to share information relating to the different external networks.
• a controller is for example an SDN controller.
• the method according to the invention selects one of said access equipment to route said application data coming from said first equipment, resp. towards said first equipment, taking into account said information relating to at least one of said external networks.
• 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 equipment supports the procedure for selecting at least one packet scheduling policy according to a embodiment of the invention.
• the selection of one of said access equipment also takes into account an identifier associated with said application data.
• an application identifier is associated with application data linked to an application of a certain type, presenting particular constraints (for example low latency).
• particular constraints for example low latency
• the invention relates to a corresponding source and/or recipient entity.
• 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 destination entity, 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 recipient entity, establishing at least one connection between said source entity and said destination entity implementing said at least one selected packet scheduling policy.
• Such an entity is particularly suitable for implementing the data traffic management method described above.
• the source entity, resp. recipient will of course be able to support the different characteristics relating to the process according to the invention, which can be combined or taken in isolation.
• 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. Therefore, they are not detailed further.
• One 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 computer-readable information medium comprising instructions for at least one computer program as mentioned above.
• 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 equipment connected to the same local network
• Figures 4A to 4B illustrate the selection of access equipment as an exit point taking into account information transported in the channel of Figure 3
• Figure 5 illustrates the selection of access equipment as an exit point taking into account an application identifier
• Figure 6 illustrates an example of channel point-to-point established to share information between two access equipment connected to the same local network
• Figures 7A to 7B illustrate the selection of access equipment 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 recipient entity according to a particular embodiment of the invention
• 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 (close 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.
• application data represents 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.
• 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 which are the subject of a data exchange between the source and recipient entities, which allows a level of granularity adapted to the variety of these applications and traffic profiles. This configuration is therefore not "global”, that is to say it is not generic (that is to say whatever the number and nature of the applications which motivate the exchange of data between source and recipient entities), nor systemic (that is to say that the application of 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).
• different packet scheduling policies can be dynamically negotiated and implemented for different reference connections established between entities connected to at least one network.
• 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 which connect the source and destination entities.
• the proposed solution contributes to the optimization of the use of intra- and inter-site resources. , so that traffic routing 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).
• 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 therefore anticipate) possible degradations in the quality of experience which could, for example, be caused by network failures (breakage or overload of communication links, overload of communication equipment). switching, etc.).
• the proposed solution does not call into question 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 on a given site.
• 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 recipient entity 12.
• 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 (noted for example PSS for “Packet Scheduler SCHEMATICS ”) of application data, exchanged between the source entity 11 and the recipient entity 12, taking into account at least one characteristic of an application associated with the application data.
• a characteristic is of the type maximum transit delay, maximum packet loss rate, preservation of the confidentiality of the information exchanged, etc.
• said at least one selected packet scheduling policy is supported by the source entity 11 and by the destination entity 12.
• a prior step of checking the capabilities of the source entity 11 and/or of the recipient entity 12 can be implemented to determine the packet scheduling policy(ies) supported by the source entity 11 and by the recipient entity 12.
• the data traffic management technique also implements the establishment 14 of at least one reference connection between the source entity 11 and the destination entity 12.
• 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 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).
• the identifiers of these policies can be exposed via APIs dedicated to accessing the modules responsible for applying these policies.
• such a reference connection uses a transport layer protocol, such as the QUIC protocol, which makes it possible to improve the security of exchanges between the source entity and the recipient entity.
• the reference connection may rely on the use of another protocol (e.g., TCP (with or without the MPTCP option), GRE, GTP, IKE).
• the source entity can be a first piece of equipment, for example a terminal, connected to a local network
• the destination entity can be a second piece of equipment , connected to at least one external network, for example a remote server, a second terminal, etc.
• the source entity (resp. recipient) can be access equipment, connected to a local network and to at least one external network, routing application data from (resp. to) a first equipment connected to the local network
• the recipient entity can be a second piece of equipment connected to at least one external network, for example a remote server, a second terminal, etc.
• the source entity can be access equipment, connected to a local network and to at least one external network, routing application data from (resp. to) a first equipment connected to the local network, and the recipient entity (resp. source) can be a hub, routing the application data to (resp. coming from) a second piece of equipment connected to at least one external network.
• the local or wide area network can be a home network, a corporate network, a university campus network, an industrial network that connects robots on a site or that interconnects several production sites, etc.
• IP connectivity may be provided via a wired network, or wireless (e.g. 5G, Beyond 5G (B5G), 6G), or both.
• a WAN network as illustrated in Figure 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 networks d 'access.
• One or more terminals, or hosts, Hl, H2, H3 are connected to the LAN 21.
• One or more access equipment, or “Customer Equipment”, CEI, CEk are also connected to the LAN 21. This access equipment makes 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.
• one or more access devices can be used to connect a local network to the same external network: for example the CEI and CEk access devices make it possible to connect the local network 21 to the external network Net. #2 222, the same access equipment can be used to connect a local network to several access networks: for example the CEI access equipment makes it possible to connect the local network 21 to the external networks Net. #1,221 and Net. #2 222, one or more access equipment can be used to connect a local network to several access networks: for example the CEI and CEk access equipment makes it possible to connect the local network 21 to the external networks Net. #1,221, Net. #2 222 and Net. #d 22d.
• CE is used to denote any equipment connected to a local network and which makes it possible to connect said local network to at least one external (access) network.
• a CE can in particular be a router, or equipment which simply routes traffic to or from the local network.
• a CE may in particular be placed under the operating responsibility of the local network administrator or that of an operator of one of the external networks, etc.
• 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.
• external networks can notably provide global IP connectivity (allowing access to the Internet in particular) or restricted connectivity (for example only to the sites of the same company, to access to resources hosted in “cloud” infrastructures). » private or public, etc.).
• global IP connectivity allowing access to the Internet in particular
• restricted connectivity for example only to the sites of the same company, to access to resources hosted in “cloud” infrastructures). » private or public, etc.
• one or more can be dedicated to the connection of a single site (this is the frequent case of companies wishing to benefit from a exclusive connectivity and not shared with other entities).
• these different accesses can be operated by the same operator or by separate operators.
• communications between company sites can be of different types:
• hub-spoke-disjoint this mode is similar to “hub-and-spoke” mode except that the “Hubs” cannot communicate with each other.
• the invention finds applications in particular in these different contexts.
• a CE can communicate via all or part of these different external networks with at least one network element, called “network concentrator” or “concentrator”, via dedicated reference connections typically based on the establishment of tunnels.
• network concentrator or “concentrator”
• At least one concentrator 23 can be deployed in at least one of the external networks 221, 222, 22j.
• the first equipment is a terminal Hl, which requires the execution of an application hosted by the server S.
• the application data exchanged between the terminal Hl and the server S are transported on an “application” connection between the terminal Hl and the server S, illustrated in dotted lines in Figure 2.
• the terminal Hl 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 Hl and /or the server S.
• a reference connection according to the invention can then be established between the terminal Hl and the server S.
• the application connection and the reference connection can be the same connection.
• the traffic distribution can be managed by at least one piece of equipment IEC, CEk network access local and/or the server S.
• a reference connection according to the invention can then be established between the access equipment and the server. Such a reference connection can in particular be associated with the application connection for the routing of application data between the terminal and the server via the access equipment.
• the traffic distribution can be managed by at least one IEC access equipment, 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 equipment and the concentrator.
• Such a reference connection can in particular be associated with the application connection for the routing of application data between the client and the server via the access equipment and the concentrator.
• the steps described below for a CE can more generally be implemented by a source entity and the steps described below for a concentrator by a recipient entity.
• the source entity may be a concentrator and the destination entity a CE.
• a CE can be configured with at least one piece of information making it possible to identify or reach at least one concentrator.
• concentrators can be declared to the same CE, for example by means of a static configuration or a dynamic configuration using a protocol such as DHCP or CWMP or NETCONF, to provide the identification / reachability information of the concentrators.
• the concentrator can be an “SD-WAN GW” gateway (“SD-WAN Gateway” in English).
• the information enabling a hub to be identified includes, for example, one or more IP addresses (IPv4 and/or IPv6), one or more port numbers, and/or an authentication identifier, etc.
• an authentication identifier can in particular be used to verify the authorization of a concentrator to establish a reference connection with a CE. This identifier can 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 path established between the CE and the hub.
• the addresses and/or port numbers can in particular be used as addresses and/or port numbers destination of reference connections to identify a hub.
• a concentrator is notably configured to be able to route data received from one CE to another CE, to (resp. from) a server located in a public or private “cloud”, or more generally, to (resp. from) a server connected to the Internet. Additionally, a concentrator may maintain entries in a table, for example a Binding Information Base (BIB), whose entries allow the concentrator to select the relevant CE to which return traffic will be routed.
• BIOS Binding Information Base
• At least one data packet scheduling policy can be selected for a source entity/recipient entity pair.
• a data packet scheduling policy may in particular support all or part of the following functions: management of available paths, congestion management, reassembly of packets, reordering of packets, etc.
• a PSS may possibly take into account other parameters for the execution of the functions described above, 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 induced costs, balancing of path usage, etc.), the experience of using (past, historical) the resources associated with each external network, which allows for example to qualify the stability of certain resources in use and to implement appropriate maintenance policies.
• An entity implementing the invention can 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.
• an entity implementing the invention can 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.
• An entity implementing the invention can in particular establish at least one reference connection between the source entity and the destination entity, on which the selected PSS is implemented.
• 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.
• An entity implementing the invention can 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 quality of experience (QoE, “Quality of Experience”) for a given application.
• a function is based for example on the exploitation of data which can be processed by artificial intelligence techniques such as machine learning (“Machine Learning” in English) and the use of specific learning algorithms (for example example a reinforcement learning algorithm, or “Reinforcement Learning” in English) and is executed locally (typically supported by a CE).
• Such a function makes it possible, for example, to monitor: the fill rate of queues: monitoring of 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 one-way transit delay such as 'observed on a path, a round trip time RTT (“Round-Trip Time” in English) as observed on a path, and in particular a path allowing access to a concentrator, a loss of packets observed on a path, a variation of an inter-packet delay (“Inter-Packet Delay Variation”) or jitter, advanced application parameters calculated by robots which emulate certain applications (for example of the VoIP robot type, Webex® robot), a history of congestion observed on a path, etc.
• Inter-Packet Delay Variation Inter-Packet
• a CE resp. a concentrator
• actions characteristic of the application of a PSS depending on the quality of service or QoE constraints of the applications, for example example.
• Such actions may consist of executing certain algorithms such as: “Round-robin” type algorithm: the paths (also called “links”) are invoked cyclically according to an exit point (CE, for traffic from LAN to an external network), associated with each path.
• the weight of each path can be fixed by an administrator or be calculated (dynamically) according to several parameters (for example optimization of the costs of the reference connection), optimization of the storage time of packets in the queues. waiting by means of time interval management,
• Priority-based priorities are assigned to each path, for example taking into account a PBR policy (“Policy-Based Routing” in English), an RTT threshold (“RTT threshold” in English): the paths are used until a certain RTT threshold is reached.
• RTT threshold the threshold is set so that the application of the PSS can guarantee that the paths used do not present an RTT that does not conform to the applications' expectations.
• the algorithm(s) involved queue management algorithms, in particular) in the application of the PSS allows in particular proactive management of the deterioration of latency, a priority assigned to the paths with the lowest RTT (“Lowest RTT first” in English): such paths are for example preferred for routing traffic to a hub, etc.
• a CE can: source 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.
• a PSS data packet scheduling policy may be identified by a unique identifier.
• a PSS can be identified by an integer, a name, etc.
• the PSS by “couple” source entity/recipient entity can 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 ).
• the CE When establishing a first reference connection from a CE to a concentrator, the CE (for example the IEC) checks whether the concentrator 23 supports the procedure for selecting at least one packet scheduling policy according to the invention. Alternatively, the CE can use a dedicated connection to check if the hub supports said procedure. This connection is then closed and is therefore not used to transport application data.
• the source entity receives the “Customized_PSS” parameter valued at “0x1” from the recipient entity (concentrator 23 for example)
• the source entity can send to the recipient entity a list of the or packet scheduling policies supported by the source entity.
• the source entity can use a new QUIC frame, called here QUIC PSS frame, to inform the entity recipient of the packet scheduling policy(ies) supported by the source entity.
• the recipient entity can keep in memory the list of PSS supported by the source entity, in particular for the management of return traffic.
• the recipient entity can send to the source entity a list of the packet scheduling policies supported by the recipient entity (in particular if the source entity has not communicated to the recipient entity the PSS supported by the source entity), or a selection of packet scheduling policies supported by the source entity and the destination entity.
• the source entity receives a list of PSS supported by the destination entity in a QUIC PSS frame: PSS#1, ..., PSS#i.
• the source entity can in particular keep in memory the list of PSS supported by the recipient entity.
• the transmission from the recipient entity to the source entity of the list of PSS supported by the recipient entity can be implemented on a regular basis, for example every 24 hours, to refresh the list of PSS kept in a memory of the source 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 recipient entity. Such characteristics may notably include constraints of the application in question.
• Such a reference connection is based for example on the QUIC protocol.
• the selection of at least one PSS is carried out before establishing the reference connection.
• the source entity selects a PSS to activate for the reference connection (associated with an application or a group of applications of the same type) and communicates the PSS identifier to the recipient entity.
• the source entity and the destination entity then activate the same PSS for this reference connection.
• the selection of at least one PSS is carried out simultaneously with the establishment of the reference connection. Note that the application of the same PSS can be carried out for one or more reference connections established between the source entity and the destination entity.
• 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 negotiation of the PSS is carried out beforehand between the source entity and the destination 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 valued at “0x1” has not been exchanged between the source entity and the destination entity.
• the source entity for example the CE
• sub-connections also called multi-path connection
• the establishment of sub-connections makes it possible to switch/redirect traffic to one path or another, for example according to the QoE objectives set by an application or according to the evolution of transmission conditions (degradation of the transit time for example).
• the source entity negotiates with the hub the application mode of the PSS to be implemented for the application flows transported on this reference connection.
• the negotiation is carried out during the establishment of the communication characteristic of the application used between the terminal and the server, also called application connection.
• the data packets transmitted on the reference connection are then distributed between the different paths according to the mode of application of the activated PSS and according to the quality of service and QoE conditions observed by the source entity.
• traffic classification information can be provided to the source entity and/or the destination entity to associate an application type with a packet scheduling policy that would satisfy, for example, example, the quality requirements linked to this type of application.
• 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.
• This classification information can be: configured by an administrator using a management interface specific to the source and/or recipient entity, communicated via a signaling mechanism such as the PCP (“Port Control 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 conditional on an agreement between the server provider and the entity which 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 document RFC6897 “Multipath TCP (MPTCP) Application Interface Considerations” of March 2013 or “QUIC API for Peer-to-peer Connections” from the W3C Community Group Draft report of March 3, 2022, etc.
• a signaling mechanism such as the PCP (“Port Control 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 conditional on an agreement between the server provider and
• the source entity can in particular select the mode of application of a PSS to be implemented to associate the traffic received 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, an evolution of the transmission conditions (for example degradation of the latency time observed on a reference connection or a sub-connection).
• the traffic is then associated with an egress interface of the source entity and then routed over the associated subconnection(s).
• the source entity and the destination entity can use different paths to route outbound traffic and return traffic if the quality of service or QoE objectives are not met. satisfied only in one direction of traffic routing (CE to hub or hub to CE), for example.
• the source entity can send an alert to the entity which has management responsibility, for example the SDN controller of the site where the source entity is deployed.
• the source entity is access equipment and the destination entity is a concentrator (traffic coming from the LAN and destined for an external network).
• the operations described above can be implemented in the case where the source entity is a hub and the destination entity is access equipment (traffic coming from the external network and destined for the LAN).
• the operations described above can be implemented by a first piece of equipment 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 equipment such as another terminal, a server, etc., if it supports a procedure for selecting at least one packet scheduling policy according to the invention.
• the source entity can be a terminal and the destination entity a server (or vice versa), the source entity can be access equipment and the destination entity a server (or vice versa), The source entity can be a hub and the destination entity a server (or vice versa), the source entity can be access equipment and the destination entity a hub (or vice versa).
• a particular embodiment is described below according to 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 (resp. entry point) of the LAN.
• the different CEs connected to the same local network can in particular use a dedicated channel to share between them information relating to the different external networks, for example information characteristic of the traffic passing through the CEs connected to the external networks. 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.
• the dedicated channel can be of the “point-to-multipoint” type.
• CEI access equipment can thus receive information relating to at least one of the external networks coming from at least one other CE2, CE3, CEk access equipment 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 of the CEs subscribe to the same multicast group defined by an address of particular group. This multicast address is declared in all 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.
• the information received by a CE (for example CE2 in Figure 3) from other CEs (for example CEI) can thus feed a path selection procedure implemented by the CE, to route the data received from connected terminals to the local network to one or more hubs.
• Such information is for example characteristic of the different traffic passing through the different CEs, such as pairs ⁇ source address; destination address ⁇ .
• this information can be used by at least one CE to modify the routing in the local network for application data traffic in accordance with the packet scheduling policy selected for the application associated with this application data.
• this information can be used by at least one CE to determine the exit point (“egress point”, in English) of the application data traffic according to different criteria such as the destination of the traffic transmitted by a terminal connected to the network. local, the nature of the traffic transmitted by a terminal connected to the local network and whose constraints in terms of latency or inter-packet delay variation may impose one path rather than another to reach a concentrator, etc.
• the selection of a CE will be conditioned by its ability to contribute to respecting the level of quality of experience (QoE) characteristic of the nature of the service or the application used by a terminal connected to the local network to achieve a given destination.
• QoE quality of experience
• each of the CEs making it possible to reach said destination chooses a preferred path according to local conditions (access to the service or to a remote site, for example) such as to optimize the QoE as perceived by the user. , and announces this path in the local network.
• the CE that helps provide 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)).
• Figures 4A and 4B illustrate a first path at a time T0 and a second path at a time Tl between the terminal H2 and the server S .
• the application connection is associated (for example by the IEC) with a reference connection established between the IEC and the hub 23.
• the application connection transporting the application data between the IEC and the concentrator 23 is associated with the reference connection established between the CE and the concentrator.
• the application data therefore passes through the CEI access equipment and the external network Net. #1.
• the different access equipment CEI and CEk can notably 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) based on the QoS parameters observed by the CEs and exchanged via the channels established between the CEs of the same site (Site #i).
• 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.
• the selection of a CE 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.
• such an identifier is an application identifier, for example “app-id”.
• the “app-id” identifier can in particular be used by a terminal for the routing of packets characteristic of specific applications, also called application data.
• applications with the same QoE constraints can be identified by the same application identifier.
• an application can communicate its identifier ("app-id") via a local network API to indicate to a routing/forwarding process ("routing/forwarding", in English) embedded in a CE the "application” route to use to route data from this application within the local network.
• route announcement messages contain an application identifier that allows application-specific routes to be maintained in the local network. In doing so, a local network can then maintain differentiated routes per application, and therefore, distinct CEs can be chosen to route traffic to the same destination for a given application.
• identifiers can be used to select one route rather than another: for example, the same DSCP (“DiffServ Code Point”) coding can lead to selecting routes for traffic marked EF (“ Expedited Forwarding”) and other routes for traffic marked AF (“Assured Forwarding”), without prejudging the nature of the application(s) which will benefit from this differentiated treatment.
• a “dscp-val” identifier can be associated with the routes announced between CEs in the messages exchanged between them via a dedicated channel.
• the dedicated channel can be of the “point-to-multipoint” type.
• Figure 6 illustrates a second example in which the channel dedicated to sharing information between CEs is a “point-to-point” channel.
• 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.
• 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.
• Such a controller 61 can be local to each site. In this way, it is possible to preserve the tightness of communications between the different sites. Indeed, the decisions (routing policies, traffic redirection, management of site CEs, etc.) taken by such a controller are local to the site. In fact, these decisions do not interfere with those taken by other controllers deployed on other sites.
• Such engineering also makes it possible not to depend on connectivity between sites, which contributes to strengthening the robustness and the capacity to apply the decisions taken by the controller, without inducing additional delay or compromising the correct application of decisions, particularly when these must be taken in response to new quality of service or QoE conditions observed on the site in question.
• a single controller can be used to manage different sites where multiple CEs are deployed.
• 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.
• the controller uses the information received from the different CEs to decide on the local policy for selecting exit point(s) within of 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.
• the controller can in particular configure the CEs with routes specific to a group of applications having similar quality of service or QoE constraints.
• the “app-id” identifier can be used to demultiplex routes and be able to choose exit points (CE, for traffic originating from the LAN and destined 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 can serve as input data for the calculation of the routes (and the dynamic instantiation of the associated “application” routing policy) which will pass through this or that CE.
• Figures 7A and 7B illustrate a first path at a time T0 and a second path at a time Tl between the terminal H2 and the server S .
• 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).
• 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 sharing of information between CEs is disabled by default.
• the source and/or recipient entity comprises a memory 81, a processing unit 82, equipped for example with a programmable calculation machine or a dedicated calculation machine, for example 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.
• 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.
• the processor of the processing unit 82 implements steps of the traffic management method described above, according to the instructions of the computer program 83, 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, 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.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Data Exchanges In Wide-Area Networks (AREA)

Applications Claiming Priority (2)

Publications (1)

Family

ID=85122114

Family Applications (1)

Country Status (5)

Family Cites Families (2)

• 2022
  • 2022-09-30 FR FR2210007A patent/FR3140501A1/fr not_active Withdrawn
• 2023
  • 2023-09-27 US US19/116,973 patent/US20260113278A1/en active Pending
  • 2023-09-27 EP EP23776394.1A patent/EP4595404A1/de active Pending
  • 2023-09-27 CN CN202380069932.9A patent/CN119968832A/zh active Pending
  • 2023-09-27 WO PCT/EP2023/076689 patent/WO2024068725A1/fr not_active Ceased

Also Published As

Similar Documents

Legal Events