Method for determining a route for routing at least one packet of data correlated to application data over a communication network
Patent Information
- Application Number
- PCT/EP2026/054293
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2025-02-18
- Filing Date
- 2026-02-17
- Publication Date
- 2026-08-27
Smart Images
Figure EP2026054293_27082026_PF_FP_ABST
Abstract
Description
[0001] DESCRIPTION
[0002] TITLE: Method for determining a route for the transmission of at least one data packet correlated with application data over a communication network
[0003] technical field
[0004] The invention lies in the field of communication networks, and more particularly in that of IP networks (from the English "Internet Protocol").
[0005] Previous art
[0006] With the massive use of communication means, the improvement of transmission rates, the proliferation of applications and services, and the multiplication and sophistication of the underlying technological building blocks (such as those supported by terminals, intermediate networks, data centers, etc.), it has become common for additional data to be generated in correlation with application data packets (typically inserted into application data packets) routed via a communication network, generally without the knowledge of the users or the application that originated this application data.Such additional data - which can also be described as ancillary data in that it is not necessary for the provision of the service or specific to the application or the user - can for example be used for statistical purposes, monitoring and quality assurance of packet routing (as is the case for example with techniques such as "In-band OAM" or "In-situ Telemetry"), or for the provision of complementary services (for example a functional chaining of the type "Service Function Chaining (SFC)").
[0007] In many cases, although associated with an application data package generated by an application, this ancillary data is not part of the data necessary for the application's operation. In some cases, it can be used to optimize data routing through intermediate networks. However, it is likely to disclose information that falls under a user's privacy, or at the very least, circumvent certain application measures implemented specifically to protect access to data that a user might wish to keep private. As an example of such an application measure, an application might encrypt the application data it generates to prevent an entity within an intermediate communication network from accessing and exploiting it in plaintext.An application can also modulate the application data it transmits to prevent such an entity from identifying the application associated with those data packets through profiling techniques or the use of templates (or "traffic patterns"). However, these application measures can be rendered less effective, or even completely ineffective, if the operating system of the communication terminal running the application enriches (by default) the application data packets with unencrypted ancillary data (for example, via IPv4 options, IPv6 extensions, TCP options, UDP options, or application headers) that discloses, for example, the user's identity, their practices, or the nature of the application.In general, supplementary data is also likely to be inserted at the network equipment level during the routing of application data over a communication network, or even by the receiving terminal itself (typically a remote server) before, for example, sending a response to a request received from the application. Information disclosed by a remote terminal can facilitate the correlation of exchanged packets and thus reveal information characteristic of the application or even the user. It should be noted that several remote terminals can be involved in the same communication (for example, for a broadcast service or, more generally, point-to-multipoint communications). Similarly, the applications involved can be of various types (bidirectional, unidirectional, point-to-point, point-to-multipoint, etc.).) or even rely on different modes of transport (a single connection, a multiple connection established via multiple paths, multiple connections per path, etc.).
[0008] Such ancillary data can be used by a remote terminal for traceability or profiling operations, or by an entity in the communication network located on one of the paths used by application data to extract sensitive data and share it with a dedicated service platform for uses that may not be consented to by the user.
[0009] Therefore, there is a need for a solution that allows for better control of the insertion of ancillary data within all or part of the data packets correlated with application data exchanged during the operation of an application. Summary of the invention
[0010] The present invention describes a solution to overcome certain drawbacks of the prior art. In one aspect, the present invention relates to a method for determining a route for the transmission, via a communication network, of at least one data packet correlated with application data generated in connection with an application running on a communication terminal. This route consists of a list of autonomous systems connecting the communication terminal to at least one remote terminal. According to this method, the route is determined based on at least one attribute representing the ability of at least one of these autonomous systems to implement a process for controlling the insertion of supplementary data within the at least one data packet.
[0011] In this way, it is possible to prioritize, for the transmission of data correlated with application data via a communication network, a route that traverses, as much as possible, autonomous systems compatible with the implementation of a process for controlling the insertion of ancillary data. This allows a user to have better control over the ancillary data that may be inserted at the level of equipment in an intermediate communication network. Such a process can, for example, be implemented at the communication terminal level for determining a route to a remote terminal, at the remote terminal level for determining a route to the communication terminal, or at an intermediate node (such as a router) located between these two terminals for determining the remaining portion of a route to either of these terminals.Data correlated with application data generated in relation to an application does not presume the direction of data exchange between terminals involved in providing the service associated with a given application.
[0012] In a particular embodiment, said route is further determined based on at least one parameter representative of a desired control perimeter for the implementation of said process of controlling the insertion of ancillary data, by said at least one autonomous system having said implementation capability. In this way, it is possible to identify routes that meet specific criteria in terms of controlling the insertion of ancillary data within data packets, including criteria defined within the framework of an ancillary data insertion control policy possibly already implemented locally within the communication terminal and / or the remote terminal.More specifically, such a control policy includes a set of rules that determine, at multiple levels (construction of data packets, selection of data packet output interfaces, control perimeter, redirection, fully or partially local remote processing, etc.) a level of tolerance regarding how ancillary data should be managed in relation to data correlated with application data generated in relation to an application.
[0013] In a particular embodiment, said at least one parameter representing a control perimeter belongs to the group comprising:
[0014] a parameter representative of a request for control of insertion of ancillary data at the level of at least one layer of a protocol stack used for the transmission of said at least one data packet via said communication network;
[0015] a parameter representative of a request for control of insertion of ancillary data at the level of at least one protocol of said protocol stack used for the transmission of said at least one data packet via said communication network;
[0016] a parameter representative of a request for control of insertion of ancillary data at the level of at least one data package determined according to at least one criterion defined for said application;
[0017] a parameter representative of a request for out-of-band insertion control of ancillary data correlated to said application data.
[0018] In this way, the present technique makes it possible, in particular, to control the insertion of ancillary data that may be performed during out-of-band data generation or during the encapsulation of application or related data carried out during its transmission over the communication network. More specifically, the proposed technique allows for granular control over the insertion of ancillary data into data packets correlated with application data. Such control can be implemented at a very precise level of granularity, for example at the level of a target protocol, or at a more global level, for example at the level of a target layer independent of the protocol used.In a complementary or alternative manner, this technique also allows, where appropriate, the definition of the data packets which must be subject to the control of insertion of ancillary data (for example, only the data packets of an audio stream, only the data packets associated with keyframes of a video stream, only the data packets associated with a particular identifier, etc.).
[0019] In a particular embodiment, said method includes, at said communication terminal, a procedure for discovering the capacity of at least one autonomous system to which said communication terminal is connected to implement a process for controlling the insertion of supplementary data within said at least one data packet, and a selection of at least one output interface for the transmission of said data packet based on the results of said discovery procedure.
[0020] In this way, the communication terminal is able to access information on the capabilities of its network environment to support at least some actions enabling the control of the insertion of ancillary data in data packets correlated with application data, and therefore to favor communication channels which are known to offer guarantees in terms of control of the insertion of ancillary data when routing data packets to the remote terminals for which they are intended.
[0021] According to a particular characteristic, said application is informed of the discovery of a capacity of at least one autonomous system to which said communication terminal is connected to implement a process of controlling an insertion of supplementary data within said at least one data packet by means of an application programming interface made available by an operating system of said communication terminal.
[0022] In this way, the application has a means of becoming aware of the communication network's capacity to implement control operations for the insertion of ancillary data within data packets, and thus has the possibility of taking certain measures to protect application or related data accordingly.
[0023] According to a specific characteristic, at least one output interface for transmitting the data packet is selected by the application, using the application programming interface. In this way, the application can choose one or more preferred output interfaces for transmitting data packets related to application data over a communication network. This ensures that the application obtains certain guarantees regarding the processing carried out within the communication network during the routing of these data packets, particularly in terms of controlling the insertion of ancillary data.
[0024] In a particular embodiment, said route is determined at least in part by means of an external routing protocol BGP.
[0025] In this way, a well-known and widely used routing protocol is cleverly adapted to announce, where appropriate, that one or more autonomous systems will handle a process for controlling the insertion of ancillary data within the data packets they route. Based on this information, suitable routes—that is, routes that meet specific criteria for controlling the insertion of ancillary data within application data packets—can then be easily identified.
[0026] According to a particular characteristic:
[0027] said capability of at least one of said autonomous systems, said compatible autonomous system, to implement a process for controlling ancillary data insertion (DX) is announced by means of a BGP capability type attribute of said external routing protocol BGP;
[0028] an implementation perimeter of said process of controlling ancillary data insertion (DX) by said compatible autonomous system is announced by means of a BGP transitive attribute of said external routing protocol BGP.
[0029] In this way, the adaptation of the BGP routing protocol for the implementation of this technique is carried out without this adaptation causing a significant increase in the complexity of implementing this protocol.
[0030] In a particular embodiment, said route is determined by selecting, from a plurality of routes linking said communication terminal and said remote server, the route comprising a maximum of autonomous systems having said capacity to implement said process of controlling ancillary data insertion. In this way, mechanisms exist to select the route that offers maximum guarantees in terms of controlling ancillary data insertion, in particular when there is no route that supports in its entirety - that is to say for all the autonomous systems that compose it - a process of controlling ancillary data insertion over a given control perimeter (for example desired by a user).
[0031] In a particular embodiment, said communication network is organized into network slices, and at least one of said network slices is configured to route said at least one data stream via said determined route.
[0032] In this way, the routing of application data along a route compatible with the process of controlling the insertion of ancillary data is facilitated, thanks to the implementation of one or more dedicated network slices (different dedicated network slices can notably be configured to be associated respectively with different control perimeters, more or less restrictive depending on the needs of the application and / or a user).
[0033] In a particular embodiment, said process is implemented:
[0034] at the level of said communication terminal, for the determination of a route from said communication terminal to said remote terminal; and / or
[0035] at the level of said remote terminal, for the determination of a route from said remote terminal to said communication terminal; and / or
[0036] at the level of an edge router of an autonomous system of said route, for the determination of a remaining portion of said route between said communication terminal and said remote terminal.
[0037] In this way, the process according to the present technique can be implemented within a large number of devices and nodes of a communication network.
[0038] In a particular embodiment, said route is determined step by step, by implementing at least one iteration of the following steps, as long as said at least one data packet has not reached an autonomous system comprising a terminal for which it is intended, among said communication terminal or said at least one remote terminal:
[0039] at the level of an autonomous system of said route reached by said at least one data packet, said current autonomous system, determination of a next autonomous system of said route, from among a set of neighboring autonomous systems of said current autonomous system, said next autonomous system being selected:
[0040] among a subset of said set, consisting of autonomous systems capable of implementing said process of controlling an insertion of supplementary data within said at least one data packet, when said subset is not empty;
[0041] among said set, when said subset is empty;
[0042] transmission of said at least one data packet to said next autonomous system, said next autonomous system becoming said current autonomous system in the event of the next iteration of said steps.
[0043] In this way, a data packet is routed as a priority through autonomous systems capable of implementing a process for controlling the insertion of supplementary data within said data packet.
[0044] In another aspect, the present technique also relates to a device for determining a route for the transmission, via a communication network, of at least one data packet correlated with application data generated in connection with an application executed within a communication terminal. This route consists of a list of autonomous systems linking the communication terminal to at least one remote terminal. Such a device comprises at least one processor configured to determine the route based on at least one attribute representing the ability of at least one of the autonomous systems to implement a process for controlling the insertion of supplementary data within the at least one data packet.
[0045] Such an electronic device can, of course, exhibit the various characteristics of the route determination method according to the invention, which can be combined or considered separately. Thus, the characteristics and advantages of this route determination device are the same as those of the route determination method for routing, via a communication network, at least one data packet correlated with application data generated in connection with an application running within a communication terminal, and are not described in further detail.
[0046] In yet another aspect, the present technique also relates to a route determination system for the forwarding, via a communication network, of at least one data packet correlated with application data generated in connection with an application executed within a communication terminal. This route consists of a list of autonomous systems linking the communication terminal and at least one remote terminal. Such a route determination system comprises a plurality of autonomous systems, at least one of which includes at least one processor configured to handle the route. When this at least one autonomous system, referred to as the current autonomous system, is reached by the at least one data packet, and this at least one autonomous system does not include a terminal to which the at least one data packet is destined, either the communication terminal or the at least one remote terminal.
[0047] determine a subsequent autonomous system for said route, from among a set of autonomous systems neighboring said current autonomous system, said subsequent autonomous system being selected:
[0048] among a subset of said set, consisting of autonomous systems capable of implementing a process for controlling the insertion of supplementary data within said at least one data packet, when said subset is not empty;
[0049] among said set, when said subset is empty;
[0050] transmit said at least one data packet to said following autonomous system. According to another aspect, the proposed invention also relates to a computer program product downloadable from a communication network and / or stored on a computer-readable medium and / or executable by a microprocessor, comprising program code instructions for the execution of at least one process as described above in any of its embodiments, when this process is executed on a computer.
[0051] The proposed invention also relates to a computer-readable recording medium on which is recorded a computer program comprising program code instructions for executing the steps of a process as described above, in any of its embodiments.
[0052] Such a recording medium can be any entity or device capable of storing the program. For example, the medium may include a storage means, such as a ROM, for example a CD-ROM or a microelectronic circuit ROM, or a magnetic recording means, for example a USB flash drive or a hard drive. Alternatively, such a recording medium can be a transmissible medium such as an electrical or optical signal, which can be transmitted via an electrical or optical cable, by radio, or by other means, so that the computer program it contains is executable remotely. The program according to the invention can, in particular, be uploaded to a network, for example, the Internet.
[0053] The different embodiments mentioned above can be combined with each other for the implementation of the invention.
[0054] Figures
[0055] Other features and advantages of the invention will become more apparent upon reading the following description of a particular embodiment, given by way of simple illustrative and non-limiting example, and the accompanying drawings, among which:
[0056] [Fig 1] schematically illustrates an example of an environment for the implementation of this technique, in a particular embodiment;
[0057] [Fig 2] schematically illustrates an example of interconnections between autonomous systems of a communication network, forming routes between a communication terminal and a remote terminal, in a particular embodiment of the proposed technique;
[0058] [Fig 3] illustrates an example of an extract from a configuration file of a border router of an autonomous system, for the implementation of a process for controlling the insertion of ancillary data, in a particular embodiment of the proposed technique;
[0059] [Fig.4] illustrates an example of the formalism of a new attribute of a dynamic host configuration protocol of the DHCP type, dedicated to the announcement by a communication network of the support of a control process for the insertion of ancillary data, in a particular embodiment of the invention;
[0060] [Fig.5] illustrates an example of an exchange of messages between a communication terminal and a communication network, for the discovery of the network's capabilities to support an ancillary data insertion control process, in a particular embodiment of the invention;
[0061] [Fig 6] describes a simplified architecture of a route determination device for the routing, via a communication network, of at least one data packet correlated to application data generated in relation to an application executed within a communication terminal, in a particular embodiment of the proposed technique.
[0062] Detailed description of the invention
[0063] An example of an environment in which this technique is implemented is described in relation to Figure 1. The operation of a communication terminal (CT) is governed by at least one operating system (OS) installed on the terminal, enabling it to run one or more applications. Such a CT can take the form of a computer, tablet, smartphone, connected device, customer premises equipment (CPE), proxy server, or more generally, any software instance capable of establishing or receiving communications. The operating system (OS) and at least some of the applications installed on the terminal can exchange application data with other remote terminals (other communication terminals, servers, etc.).) reachable by the communication terminal via at least one RC communication network, such as the Internet network.
[0064] Thus, as part of its operation, an application APP running on the communication terminal TC exchanges, for example, application data DA via the RC network with another terminal, for example a remote server SRV, for the provision of a service to a user.
[0065] Application data (AD) refers to data intrinsically associated with the operation of the application. Such data includes, for example, payload data (or payload), i.e., data sent or received by an application user in the course of using the service provided by the application, as well as data intended to ensure the operation of the application, such as signaling data used, for example, to establish a connection with the remote terminal, manage user authentication, etc.
[0066] Such DA application data is to be distinguished from so-called DX ancillary data within the framework of this technique, which relates to additional data that may be inserted into data packets correlated with said DA application data.By "data packets correlated with said application data", we mean here for example data packets including application data DA (in other words application data packets, which can also be described as "in-band" or "In-Packet" packets, i.e. packets "in the band" or included in the application data packet), but also data packets which do not include application data DA but which nevertheless have a link with this application data DA (i.e. which are correlated with this application data DA), and which are for example intended to be transmitted out-of-band ("out-of-band" or also "Dedicated-Packet" in English), i.e. in a channel separate from that used for the transmission of application data packets (typically in a dedicated data packet in the context of IP communications, distinct from the application data packet but correlated to the latter).The concepts of in-band (or "In-Packet") and out-of-band (or "Dedicated-Packet") for IP communications are explained in more detail in the IETF document by C. Plgnatoro et al. entitled "Guidelines for Characterizing "OAM" draft-ietf-opsawg-oam-characterization-04", November 2024.
[0067] Such ancillary data is not intrinsically linked to the operation of the application. However, in some cases, it may be related to optimizing the paths taken by application data (AD). In other words, the absence of such ancillary data (AD) generally does not impair the operation of the application (APP). As discussed in relation to prior art, this ancillary data (AD) is often inserted into data packets without the user's knowledge, typically includes information that a knowledgeable user might legitimately not want exposed, and is susceptible to being used for purposes not consented to by the user.
[0068] The invention applies independently of the protocols used for the exchange of application data as well as the method of managing a communication.
[0069] In the context of communication between an application (APP) and a remote terminal (SRV), such DX ancillary data can be inserted into a data packet correlated with application data (i.e., transmitted within the application data packet itself or out-of-band, in a dedicated packet) at different levels:
[0070] firstly, at the NI level of the communication terminal TC itself, before transmission of application data DA generated by the application APP or out-of-band data related to this application data to a remote terminal SRV; secondly, at the N2 level of an intermediate communication network equipment RC used to route the data packets;
[0071] Thirdly, at the N3 level of the remote SRV terminal, for example before transmission of application data or out-of-band data related to this application data to the APP application running on the TC communication terminal, for example in response to a request issued by this APP application.
[0072] The technique described below relates more specifically to the control of ancillary data that may be inserted at the second layer (N2), i.e., at the level of a piece of equipment in the communication network (RC), during the routing of data packets correlated with application data generated in connection with the application (APP) from the communication terminal (TC) to the remote terminal (SRV), or vice versa. Data generated "in connection" with the application (APP) refers not only to data correlated with application data generated by the application itself, but also, where applicable, to data correlated with application data generated at the remote terminal and sent, for example, to the application (APP) as part of the operation of that application.
[0073] In this context, a method for determining a route for the transmission of at least one data packet correlated with application data via the RC communication network is proposed, based on a first aspect. The RC communication network considered is typically a wide area network, such as the Internet, which, as illustrated in Figure 2, comprises numerous autonomous systems AS1, AS2, AS3, ..., AS10, etc. An autonomous system can be defined as a set of subnets and routers managed by the same administrative authority (an organization, a company such as an internet service provider, etc.). Furthermore, at the initiative of such an administrative authority, a set of rules (or policies) can be applied within an autonomous system that it controls.In order to maintain accessibility and overall connectivity within the wide area network, including the end-to-end routing of data packets from a source device to a destination device not necessarily belonging to the same autonomous system, the different autonomous systems (AS1, AS2, ..., AS10) of the wide area communication network are interconnected.
[0074] In the context of this technique, a "route" (or path) is understood to be a sequence (or list, or chain) of autonomous systems that a data packet generated at a source terminal (for example, the TC terminal) can follow to reach a remote terminal. For example, in Figure 1, an application or related data packet sent from the TC communication terminal can follow, among others, the autonomous system route AS1=>AS2=>AS6=>AS9 or the autonomous system route AS1=>AS3=>AS7=>AS10 to reach the remote server SRV. A route in the sense of this invention more generally encompasses the concept of "path" as defined in Section 2 of RFC 9473 by R. Enghardt et al., published by the IETF in September 2023 and entitled "A Vocabulary of Path Properties".
[0075] According to the general principle of this technique, it is proposed that, when determining a route to be taken to carry a data packet through the communication network (CR), consideration should be given to an indication of the capacity of the traversed autonomous systems to implement a process for controlling the insertion of additional data (DX) within the transported data packets. In other words, this technique describes mechanisms that allow for prioritizing routes that pass (at least partially) through autonomous systems capable of applying an additional data insertion control policy that conforms to predefined preferences, for example, those of a user of the communication terminal.
[0076] An ancillary data insertion control policy includes a set of rules that constrain how data frames used to carry application data, or out-of-band data correlated to that application data, over a communication network—and therefore the associated data packets—can be generated or modified. This allows, for example, defining within which framework and at which level of a protocol stack ancillary data insertion is permitted or, conversely, denied. Such a control policy may have been previously configured at the level of a communication terminal and may be associated with one or more applications running on that terminal. An ancillary data insertion control policy can also be configured at the global level of an autonomous system, a network entity, a remote terminal, and so on.As described later, an ancillary data insertion control policy may also include rules to determine, at the device level, how data packets should be transmitted over the communication network (e.g., via redirection rules or network interface selection).
[0077] A specific embodiment is described below in which the BGP (Border Gateway Protocol) routing protocol is used and adapted for route determination according to the proposed technique. This technique is referred to here, for illustrative purposes and not as a limitation, as "ROAD" for "Routing procedure for Assisting host in managing flow siDe channels".
[0078] In the implementation of such a routing protocol, each autonomous system is identified by an identifier called an ASN (Autonomous System Number), generally encoded on 16 or 32 bits. Neighboring (or adjacent) autonomous systems are interconnected via one or more border routers (or ASBRs, Autonomous System Border Routers). An interconnection between two autonomous systems is, for example, represented by an association between the ASN1 identifier of a first autonomous system (AS1) and the ASN2 identifier of a second neighboring autonomous system (AS2), configured locally at the level of each interconnecting border router of these autonomous systems.Following the establishment of a connection, these border routers of neighboring autonomous systems exchange prefix lists—that is, lists of networks for which they know at least one route to reach them (in other words, to which they are likely to forward traffic)—along with associated attributes. These information exchanges are therefore similar to route advertisements, which are stored in routing tables at each border router (Adj-RIB-ln / Adj-RIB-Out). The list of autonomous systems traversed by a route to reach a given network is, for example, transmitted in a BGP attribute named AS_PATH (for example, an attribute AS_PATH=AS9-AS7-AS3 means that a given prefix—or network—is reachable via a route that successively traverses the autonomous systems whose ASNs are AS3, then AS7, then AS9).It should be noted that route advertisements to a given network are made in the opposite direction to the direction of traffic to that network. Another BGP attribute called NEXT_HOP is used to identify the address of the next hop to be made, that is, the address of the border router of the neighboring autonomous system to which data should be transmitted, to route traffic for a given route, as described in particular in Section 5.1.3 of RFC 4271 by Y. Rekhter et al., published by the IETF and entitled "A Border Gateway Protocol 4 (BGP-4)", January 2006.
[0079] In a particular embodiment of this technique, a new BGP attribute of type "capabilities" is used by edge routers to advertise, where applicable, the support by the autonomous system to which they belong for a process controlling the insertion of ancillary data within the data packets routed through them. More specifically, when establishing a BGP session between edge routers of neighboring autonomous systems using a BGP message of type OPEN, this capability is negotiated between each peer. Thus, an edge router can be configured to enable this capability in relation to a given neighbor.Configuration can be performed manually or automatically via a network controller sending a configuration request, formatted, for example, in a YANG language and transmitted via a network configuration protocol such as NETCONF or gNMI (for "gRPC Network Management Interface"). Figure 3 illustrates, for example, and not as a limitation, an excerpt from a configuration file that might be generated by a network controller for managing a BGP session. In this file, a BGP capability, here named ROAD_CAPABLE for illustrative purposes only, is declared in block 30 to advertise and enable support for the process of controlling the insertion of ancillary data according to this technique.However, it is appropriate that alternatives to the introduction of a new BGP attribute of type "capability" as previously presented can be implemented to indicate support for ancillary data insertion control process, such as, for example, an explicit configuration in this sense of neighboring autonomous systems, or by negotiation techniques between these autonomous systems.
[0080] To identify routes defined using this technique (i.e., routes determined taking into account the capability of the traversed autonomous systems to implement ancillary data insertion control process), and to differentiate them from conventional routes (i.e., routes established without considering this capability), a new address family identifier (also called SAFI, from the English "Subsequent Address Family Identifier") is created to mark routes on which, for at least some portions, ancillary data insertion control process is available. In the example in Figure 3, this SAFI identifier is "ROAD". During route announcements, for example via a BGP UPDATE message, this dedicated SAFI identifier is used to mark the prefixes associated with a route identified as suitable for implementing ancillary data insertion control.
[0081] In addition, at least one new transitive BGP attribute (named "road_mode" in the example in Figure 3 for illustrative purposes only and not as a limitation), meaning one that can be transmitted hop-by-hop from one autonomous network to another, is also defined to specify the scope of implementation of the ancillary data insertion control process, when such a process is supported. In a particular embodiment, this attribute, also associated with the prefixes advertised in a BGP UPDATE message, in addition to the dedicated SAFI identifier, can take the form of, or be associated with, various parameters specifying the type of control implemented on the route in question.For illustrative purposes only and not as a limitation, such parameters include, for example: a parameter representing an insertion control of ancillary data at the level of at least one layer of a protocol stack used for the transmission of at least one data packet over the communication network;
[0082] a parameter representing an insertion control of ancillary data at the level of at least one protocol of said protocol stack used for the transmission of at least one data packet over the communication network;
[0083] a parameter representing an insertion control of ancillary data at the level of at least one data packet determined according to at least one criterion defined for said application;
[0084] a parameter representative of an out-of-band insertion control of ancillary data correlated to said application data.
[0085] The rules defined in a policy for controlling the insertion of ancillary data implemented at the scale of an autonomous system thus offer the possibility of acting at different levels.
[0086] For example, in a particular embodiment, a rule prohibiting the insertion of ancillary data at the general level of one or more layers can be defined. Thus, it is possible, for example, to define a rule according to which no insertion of ancillary data is allowed in connection with the transport layer of a TCP / IP model, regardless of the IP version used (IPv4 or IPv6) or the transport protocol (for example, TCP "Transmission Control Protocol", UDP "User Datagram Protocol", SCTP "Stream Control Transmission Protocol", QUIC) actually used.
[0087] More specifically, the proposed technique also allows for the definition of one or more rules prohibiting the insertion of additional data at the level of a particular protocol within a given layer (physical, network, transport, application, etc.). For example, it is possible to define a rule whereby no additional data is allowed during encapsulation using the UDP transport protocol.Implementing such a rule results, for example, in disabling the use of any "options" available in the headers and / or trailers of data frames defined according to these protocols (in this case, either the operating system does not insert any data into these fields when constructing the data frame to be transmitted over the communication network, or the operating system removes all data present in these fields). For example, terminals participating in a QUIC connection can negotiate the disabling of UDP options for all or part of the exchanged data. Other protocols, such as TCP, HTTP, SIP, WebRTC, etc., can also be subject to the control of ancillary data insertion.
[0088] In a particular embodiment, using an alternative or complementary approach, the proposed technique also allows, within the framework of the control policy, the configuration of rules that define whether or not the insertion control of ancillary data should be performed for all application or related data. More specifically, provided that the operating system supports these different modes, it is possible to specify that the insertion control of ancillary data should be performed, for example, for all data packets emitted during the same application session, or conversely, to perform this control only for all data packets in a targeted data flow of an application session, or even only for certain clearly identified packets (using, for example, a packet identifier).For example, if the application in question is a video conferencing application, it is possible to define rules according to which the insertion of ancillary data is allowed in the audio application data stream, but not in the video application data stream. More precisely, with regard to the control applied to the video application data stream, it is also possible to configure a rule prohibiting the insertion of application data only within the data packets associated with the transmission of keyframes of that video stream.
[0089] Alternatively or in addition, one or more rules prohibiting the insertion of ancillary data at the level of out-of-band data correlated with application data can also be defined. In this way, the insertion of ancillary data can be controlled not only at the level of the communication channel used to carry application data, but also at the level of other communication channels that might be used to carry out-of-band data. Such a channel could rely on application data packet mirroring, a dedicated ICMP (Internet Control Message Protocol) packet, etc.In the case of an ICMP packet, correlation with the application data packet can, for example, be achieved by inserting into the ICMP packet a digest (or "hash" in English) of said data packet, the characteristic information of the connection (source IP address, source port number, destination IP address, destination port number, transport protocol), or a combination of the two.
[0090] The preceding examples are, of course, given for illustrative purposes only and are not exhaustive. Other types of rules (for example, based on time ranges or resource availability) can also be considered within the framework of this technique. Combining several rules is also possible. As an alternative to using a new BGP transitive attribute to indicate the control perimeter associated with a route, as described above, it is also possible to use the existing AIGP (Accumulated Interior Gateway Protocol) attribute already used in BGP implementations, by associating it with at least one new Type / Length / Value (TLV) triplet dedicated to announcing a supported ancillary data insertion control perimeter.
[0091] In any case, upon receipt of a BGP message of type UPDATE including for at least some prefixes the following SAFI address family identifier dedicated to marking a route supporting the ancillary data insertion control process possibly accompanied by at least one attribute defining the perimeter of such a control, an ASBR border router extracts this information from the received UPDATE message, and updates its local routing table accordingly, recording in particular for each received prefix values representative of an associated control perimeter.
[0092] It should be noted that, within the framework of this technique, several different routes may be associated with the same prefix in the routing table of an edge router. For example, a first route with ancillary data insertion control on a given perimeter (e.g., control at the global transport layer level of the OSI model), a second route with ancillary data insertion control on a second given perimeter (e.g., control at the specific level of the SIP protocol), a third route described as "conventional" in that it does not take into account any particular considerations regarding ancillary data insertion control, and so on. In other words, the route selection procedure is thus performed for each supported perimeter, with the selected routes being installed in the local routing table (Loc-RIB) of the edge routers.The installation of the selected routes and their subsequent propagation to neighboring autonomous systems is performed according to the standard BGP procedure. However, these routes are marked, using the techniques described previously, as associated with effective control over ancillary data insertion within a given perimeter (marking using SAFI ROAD in the example considered here). In a particular embodiment, certain routes associated with a restricted control perimeter are not maintained when it is detected that a route already exists with a broader control perimeter, encompassing the restricted control perimeter.For example, if a route prohibiting the insertion of ancillary data exists at the global transport layer, it is not necessarily useful, at least in some embodiments, to maintain a route prohibiting the insertion of ancillary data at the TCP-specific transport protocol level. In one particular embodiment, the route management procedure using the ROAD technique can be implemented by internal routers (and therefore invisible to neighboring autonomous systems).
[0093] Typically, routes are updated (added, removed, etc.) according to the availability of prefixes and associated networks. A communication terminal can reach remote servers using a conventional route or a route on which an additional data control process is implemented (note that these two routes can be different, i.e., with distinct AS_PATHs, but also sometimes identical in terms of the autonomous systems traversed).
[0094] Depending on the prefixes to be reached, it is possible that no route exists that fully supports—that is, for all the autonomous systems that comprise it—a process for controlling ancillary data within a given control perimeter (for example, as desired by a user). In other words, for some prefixes, controlling the insertion of ancillary data is sometimes only possible, at best, for certain portions of the route, within the autonomous systems that have the capability. In such a situation, selection criteria (forming a selection policy) can be defined in addition to the route determination mechanism described earlier, so as to establish rules for choosing a preferred route for data transmission on the communication network.
[0095] For example, if a route (i.e., an AS_PATH) is absent for a given prefix, and all autonomous systems are capable of implementing ROAD_CAPABLE insertion control, predetermined selection criteria can dictate that the path whose AS_PATH maximizes the number of consecutive ROAD_CAPABLE-compatible autonomous systems should be selected as the priority path by the source autonomous system. According to a particular characteristic, the closer this consecutive list is to the source autonomous system (in terms of autonomous system hops), the more preferred the route is for a given prefix.Other selection policies can of course be implemented within the framework of this technique; for example, one can consider selecting the path whose AS_PATH maximizes the number of consecutive ROAD_CAPABLE autonomous systems that are closest to the source (or destination) autonomous system. Thus, for example, in a particular embodiment, a route can be determined step by step. More specifically, as long as a data packet to be routed has not yet reached an autonomous system containing the terminal to which it is destined, the autonomous system reached by this data packet—in other words, the current autonomous system on the packet's route—determines a subsequent autonomous system to which to forward the packet, among its neighboring autonomous systems.The next autonomous system is selected as the priority among neighboring autonomous systems capable of implementing a process to control the insertion of supplementary data within at least one data packet. If no such autonomous system is identified, a neighboring autonomous system lacking this capability is selected. The data packet is then transmitted to the next autonomous system thus determined, which becomes the current autonomous system for the subsequent iteration of the routing mechanism just described.
[0096] The specific embodiments described above, based on an adaptation of the BGP routing protocol, are given for illustrative purposes only and are not exhaustive; the general principle according to this technique can also be implemented in connection with other contexts and / or technical solutions, for example:
[0097] by relying on a route selection engine based on a SCION architecture (from the English "Scalability, Control, and Isolation On Next-generation networks") via the grouping of autonomous systems within a control plane isolation domain (ISD, for "Isolation Domain" in English) dedicated to the control of insertion of ancillary data;
[0098] by defining a logical topology dedicated to the control of insertion of ancillary data for the use of a multi-topology routing protocol from intermediate system to intermediate system (M-ISIS, from the English "Multi Topology Routing from Intermediate System to Intermediate System" as described in the RFC 5120 document by N. Shen et al. published by the IETF in February 2008) or an NRP partition ("Network Resource Partition" in English);
[0099] by defining a source routing mode where each autonomous system interconnects with an autonomous systems reputation platform regarding support for ancillary data insertion control, reputation then being taken into account for route selection.
[0100] In a particular embodiment, when the communication network is organized into slices, one or more network slices can be configured to be dedicated to the routing of application data or linked along a route compatible with the ancillary data insertion control process, for a given control scope. When a data packet is received via a dedicated network slice, the packet is routed using the routing table corresponding to the previously installed "road_mode" (Loc-RIB) for that slice. The BGP routing table is then used to select intermediate ASes consistent with the objectives of that slice. This procedure is repeated by each intermediate AS until the data packet is presented to the remote terminal.
[0101] In addition to the aspects described above, the present technique also includes, at the level of the communication terminal, mechanisms for discovering the medium (i.e. compatibility), by at least one communication network to which it is connected, the process of controlling the insertion of ancillary data, and the selection of an associated network interface.
[0102] These discovery mechanisms are implemented, for example, at each startup of the communication terminal, or at regular intervals, etc. When the communication terminal is connected to at least one communication network that supports (at least in part) the process of controlling the insertion of ancillary data, it can store this information in a dedicated parameter, for example by setting a dedicated parameter (named for example "HASH_FORWARDING") to the value "true", which can then be exposed to applications running on the communication terminal, for example by means of an application programming interface (or API) made available by the operating system of the communication terminal.
[0103] More specifically, such an application programming interface exposes, for example, accessor (GET) and mutator (SET) type methods allowing an application running on a communication terminal not only to obtain, among other things, information on the ability of the communication terminal's operating system to implement, at the local level, control of the insertion of ancillary data and on what scope, but also to set configuration choices of the ancillary data insertion control policy with respect to the application in question.
[0104] Through such an application programming interface, as previously presented, the insertion of supplementary data can be controlled at different levels of granularity, for example:
[0105] at the global level of at least one layer of a multilayered data transmission model, such as an OSI or TCP / IP model;
[0106] at the level of at least one particular protocol associated with a layer of such a multilayer model; for all data packets of the same application session, whatever they may be, or on the contrary at the level of sessions, data streams, particular data frames identified according to one or more given criteria (based on an identifier, a type of stream, a particular nature of certain data frames, etc.);
[0107] at the level of data intended to be transmitted out of band;
[0108] etc.
[0109] These different rules can obviously be combined, allowing for very precise and customized configuration of ancillary data management related to an application or group of applications. The set of rules defining an ancillary data insertion control policy associated with an application can be called a "profile." Such a profile may have been generated by the application provider and / or customized by a user, for example, using a graphical profile management interface provided by the application or the operating system.
[0110] The application programming interface exposes, for example, a GET_HASH_FORWARDING method allowing an application to know if at least one communication network to which the communication terminal is connected is compatible with an ancillary data insertion control process, and, if so, to select a network interface to use accordingly.
[0111] Support for the insertion control process by an RC communication network can be advertised to the communication terminal in various ways. In one particular embodiment, a protocol such as the Dynamic Host Configuration Protocol (DHCP) or a Neighbor Discover option (RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)") can be used for this purpose. For example, a new DHCPv6 option, illustrated in relation to [the relevant section], can be defined for this purpose. Such an option, called OPTION_V6_ROAD, allows, among other things, the advertising of various pieces of information specifying the network's support scope for the insertion control process, via various parameters specifying, for example, a supported mode and scope.Mode 41, for example, defines, while scope 42 defines, for example, at which level of at least one OSI layer or at least one particular protocol the ancillary data insertion control process can be implemented by the network under consideration. Of course, these parameter examples are given for illustrative purposes only and are not exhaustive; other parameters could be considered within the framework of this technique, such as a parameter representing characteristic information to constrain packet routing (for example, a tunnel).
[0112] An example of message exchange between a communication terminal and the RC network is illustrated in relation to Figure 5, in a particular embodiment. Such a DHCP session typically includes:
[0113] a SOL discovery message (from the English "Solicit") issued by a TC communication terminal acting as a CLT-DHCPv6 DHCP client to the RC network of which at least one entity is capable of acting as an SRV-DHCPv6 DHCP server;
[0114] in response to the SOL discovery message, at least one ADV (Advertise) message issued by at least one DHCP server on the RC network, typically including an offer of an IP address to the TC client;
[0115] following the selection of an offer by the TC client, the issuance by this client, to the RC network, of a REQ (from the English "Request") requesting the assignment of an IP address by the DHCP server whose offer was selected;
[0116] In response to this request, the selected DHCP server issues a REP (Reply) confirming the assignment of the IP address to the TC client.
[0117] As illustrated in Figure 5, the OPTION_V6_ROAD option and its parameters can be transmitted to the communication terminal via the ADV advertisement and REP response messages described earlier, thus enabling the communication terminal TC to become aware of the network's capabilities regarding its support for the ancillary data insertion control process.
[0118] In order for the TC communication terminal to become aware of the capabilities of the RC network, including in cases where the connection of the TC communication terminal to the RC communication network is not direct, but is established via one or more intermediate gateway-type equipment (“Gateway” or “Customer Premises Equipment” CPE in English), the discovery procedure described above is recursive.
[0119] The selection of a network interface for transmitting application data packets can then be performed by the communication terminal, based on the results of the discovery procedure, and more specifically on the identified capabilities to support the ancillary data insertion control process for the various communication networks to which the communication terminal is connected. The network interface can be determined in such a way as to select a network capable of applying an ancillary data insertion control policy operating within the same scope as a control scope already implemented locally on the communication terminal.Thus, a user and / or an application has the possibility of preventing or at least better controlling the insertion of ancillary data generally carried out without their knowledge, both locally and on the route taken by application or related data on a communication network, in the context of information exchanges with a remote terminal carried out as part of the operation of the application.
[0120] The previously described mechanisms for determining a route can obviously be applied to determining a route in either direction (for example, from the communication terminal to the remote terminal) or the other (for example, from the remote terminal to the communication terminal). Similarly, the network interface selection mechanisms, primarily described in relation to the communication terminal, can also be implemented at the remote terminal level, with which the communication terminal exchanges application data, in connection with the operating system that governs the remote terminal's operation.
[0121] In another aspect, the proposed technique also relates to a device for determining a route for the transmission, via a communication network, of at least one data packet correlated with application data generated in connection with an application running within a communication terminal. This route consists of a list of autonomous systems connecting said communication terminal and at least one remote terminal. Such an electronic device is capable of carrying out the method described above in any of its embodiments. More specifically, such a device according to the present technique comprises at least one processor configured to determine such a route, taking into account at least one attribute representing the ability of at least one of said autonomous systems to implement a process for controlling the insertion of supplementary data within at least one transmitted data packet.
[0122] Such an electronic device can, for example, be implemented:
[0123] within the communication terminal, for determining a route from said communication terminal to said remote terminal;
[0124] within said remote terminal, for the determination of a route from the remote terminal to said communication terminal;
[0125] at the level of an edge router of an autonomous system of said route, for the determination of a remaining portion of said route between said communication terminal and said remote terminal.
[0126] Figure 6 schematically and in a simplified manner represents the structure of such an electronic device in a particular embodiment. According to the proposed technique, the device comprises, for example, a memory 61 consisting of a buffer memory M, a processing unit 62, equipped, for example, with a microprocessor pP, and controlled by the computer program Pg 63, implementing the steps of the route determination process according to at least one embodiment of the invention.
[0127] At initialization, the code instructions of computer program 63 are loaded into the buffer memory before being executed by the processor of the processing unit 62. The processing unit 62 receives as input E, for example, information on the capacity of one or more autonomous systems neighboring the autonomous system comprising the electronic device to be implemented, a control process for an insertion of ancillary data within at least one packet of data correlated with application data routed within or beyond them.
[0128] The microprocessor of the processing unit 62 then carries out the following steps of the control process, according to the instructions of the computer program 63. More in particular, the processing unit 62 evaluates, with regard for example to a predetermined control policy for the insertion of supplementary data, and according to at least one of the embodiments previously described, different routes allowing to reach the remote terminal receiving the data, so as to deliver at output S of the processing unit 62 a route to be preferred for the routing of the data packets, which respects as far as possible the established control policy.
[0129] In another aspect, the proposed technique also relates to a route determination system for the forwarding, via a communication network, of at least one data packet correlated with application data generated in connection with an application executed within a communication terminal. This route is formed by a list of autonomous systems connecting said communication terminal and at least one remote terminal. More specifically, such a route determination system comprises a plurality of autonomous systems, at least one of which includes at least one processor configured to handle the route. This processor is configured to handle the route when said at least one autonomous system, referred to as the current autonomous system, is reached by said at least one data packet, and said at least one autonomous system does not include a terminal to which said at least one data packet is destined, either among said communication terminal or said at least one remote terminal.
[0130] determine a subsequent autonomous system for said route, from among a set of autonomous systems neighboring said current autonomous system, said subsequent autonomous system being selected:
[0131] -- among a subset of said set, consisting of autonomous systems capable of implementing a process for controlling the insertion of supplementary data within said at least one data packet, when said subset is not empty;
[0132] among said set, when said subset is empty;
[0133] transmit said at least one data packet to the following autonomous system.
Claims
DEMANDS 1. Method of determining a route for the routing, via a communication network (CR), of at least one data packet correlated with application data (AD) generated in relation to an application (APP) executed within a communication terminal (CT), said route being formed of a list of autonomous systems linking said communication terminal and at least one remote terminal (RV), said method being characterized in that said route is determined according to at least one attribute representative of a capacity of at least one of said autonomous systems to implement a process of controlling an insertion of supplementary data (DX) within said at least one data packet.
2. Method according to claim 1, characterized in that said route is further determined as a function of at least one parameter representative of a desired control perimeter for the implementation of said control process of an insertion of ancillary data, by said at least one autonomous system having said implementation capability.
3. A method according to claim 2, characterized in that said at least one parameter representative of a control perimeter belongs to the group comprising: a parameter representative of a request for control of insertion of ancillary data at the level of at least one layer of a protocol stack used for the transmission of said at least one data packet via said communication network; a parameter representative of a request for control of insertion of ancillary data at the level of at least one protocol of said protocol stack used for the transmission of said at least one data packet via said communication network; a parameter representative of a request for control of insertion of ancillary data at the level of at least one data package determined according to at least one criterion defined for said application; a parameter representative of a request for out-of-band insertion control of ancillary data correlated to said application data.
4. Method according to any one of the preceding claims, characterized in that it comprises, at the level of said communication terminal, a procedure for discovering the capacity of at least one autonomous system to which said communication terminal is connected to implement a process for controlling ancillary data (DX) insertion within said at least one data packet, and a selection of at least one output interface for the transmission of said data packet based on the results of said discovery procedure.
5. Method according to claim 4, characterized in that said application is informed of the discovery of a capability of at least one autonomous system to which said communication terminal is connected to implement a process of controlling an insertion of supplementary data within said at least one data packet by means of an application programming interface made available by an operating system of said communication terminal.
6. Method according to claim 5, characterized in that said at least one output interface for the transmission of said data packet is selected by said application, by means of said application programming interface.
7. A method according to any one of the preceding claims, characterized in that said route is determined at least in part by means of an external routing protocol BGP.
8. A method according to claim 7, characterized in that: said capability of at least one of said autonomous systems, said compatible autonomous system, to implement a process for controlling ancillary data insertion (DX) is announced by means of a BGP capability type attribute of said external routing protocol BGP; A perimeter for the implementation of said process of controlling ancillary data insertion (DX) by said compatible autonomous system is announced by means of a BGP transitive attribute of said external routing protocol BGP.
9. Method according to any one of the preceding claims, characterized in that said route is determined by selecting, from a plurality of routes linking said communication terminal and said remote server, the route comprising a maximum of autonomous systems having said capacity to implement said process of controlling ancillary data insertion.
10. A method according to any one of the preceding claims, characterized in that said communication network is organized into network slices, and in that at least one of said network slices is configured to route said at least one data stream via said determined route.
11. A method according to any one of the preceding claims, characterized in that it is implemented: at the level of said communication terminal, for the determination of a route from said communication terminal to said remote terminal; and / or at the level of said remote terminal, for the determination of a route from said remote terminal to said communication terminal; and / or at the level of an edge router of an autonomous system of said route, for the determination of a remaining portion of said route between said communication terminal and said remote terminal.
12. A method according to any one of the preceding claims, characterized in that said route is determined step by step, by implementing at least one iteration of the following steps, as long as said at least one data packet has not reached an autonomous system comprising a terminal for which it is intended, among said communication terminal or said at least one remote terminal: at the level of an autonomous system of said route reached by said at least one data packet, said current autonomous system, determination of a next autonomous system of said route, from among a set of autonomous systems neighboring said current autonomous system, said next autonomous system being selected: from a subset of said set, consisting of autonomous systems capable of implementing said process of controlling an insertion of supplementary data within said at least one data packet, when said subset is not empty; among said set, when said subset is empty; transmission of said at least one data packet to said next autonomous system, said next autonomous system becoming said current autonomous system in the event of the next iteration of said steps.
13. Device for determining a route for the routing, via a communication network (CR), of at least one data packet correlated with application data (AD) generated in relation to an application (APP) executed within a communication terminal (CT), said route being formed of a list of autonomous systems linking said communication terminal and at least one remote terminal (RV), said device being characterized in that it comprises at least one processor configured to determine said route based on at least one attribute representative of the ability of at least one of said autonomous systems to implement a process for controlling the insertion of supplementary data (DX) within said at least one data packet.
14. A route determination system for the forwarding, via a communication network (CR), of at least one data packet correlated with application data (AD) generated in connection with an application (APP) executed within a communication terminal (CT), said route being formed from a list of autonomous systems linking said communication terminal and at least one remote terminal (RV), said route determination system comprising a plurality of autonomous systems of which at least one autonomous system includes at least one processor configured to, when said at least one autonomous system, referred to as the current autonomous system, is reached by said at least one data packet, and said at least one autonomous system does not include a terminal to which said at least one data packet is destined, either among said communication terminal or said at least one remote terminal: determine a subsequent autonomous system of said route,among a set of neighboring autonomous systems, the following autonomous system being selected: among a subset of said set, consisting of autonomous systems capable of implementing a process for controlling the insertion of supplementary data within said at least one data packet, when said subset is not empty; among said set, when said subset is empty; transmit said at least one data packet to the following autonomous system.
15. Product computer program downloadable from a communication network and / or stored on a computer-readable medium and / or executable by a microprocessor, characterized in that it includes program code instructions for the execution of a process according to any one of claims 1 to 12, when executed by a computer.