WO2025078600A1 - Methods for verifying, for managing, for controlling and for performing a verification of the accessibility of an equipment, and corresponding equipment, control server, network controller, relay entity and computer program - Google Patents

Abstract

The invention relates to a method for verifying the accessibility of an equipment with a view to routing data to the equipment via at least one network slice, comprising: - receiving (412), via at least one secure channel (50) between the equipment and at least one control server (45), information relating to at least one verification message corresponding to at least one action of verifying the accessibility of the equipment (41) via at least one network slice that is to be performed, - verifying (414) the performance of the at least one action using this information.

Description

DESCRIPTION

TITLE: Methods for verifying, managing, controlling, and performing a verification of the accessibility of equipment, equipment, control server, network controller, relay entity, and corresponding computer program.

1. Technical domain

The field of the invention is that of communications within at least one communications network, and in particular the field of value-added IP services.

More specifically, the invention relates to the routing of data to equipment which uses network slice resources.

In particular, the invention proposes a solution for verifying the accessibility, also called reachability, of a device for return traffic (i.e. traffic to the device) via at least one network slice or one type of network slice.

2. Prior art

A network slice can be defined as a logical or physical partition of the network, such as a virtual private network (VPN) deployed on fixed infrastructure, mobile infrastructure, or a combination of both.

The characteristics of a network slice are mainly expressed in terms of capacity (bandwidth) and quality of service (e.g. latency or one-way transit time), or even security (e.g. preservation of the confidentiality of information transmitted within the VPN through the use of encryption techniques) and service functions (“Service Functions (SF)”).

For example, the 3GPP organization has defined different types of network slices according to their characteristics, for example: a first type of network slices allowing to offer an enhanced mobile broadband service ("enhanced Mobile BroadBand" or eMBB in English); a second type of network slices allowing to offer a service as part of a (massive) deployment of the Internet of Things ("massive Internet of Things" or mloT in English); and a third type of network slices allowing to offer an ultra-reliable and low-latency communication service ("Ultra Reliable Low Latency Communications" or URLLC in English).

The choice of designing and deploying a type of network slice is conditioned by the nature of the traffic characteristic of the applications or services used or subscribed to by a user. For example, a so-called "immersive" service that uses augmented or virtual reality techniques is generally very demanding in terms of latency and reliability of data exchanges: the use of URLLC type slices is therefore preferred for an immersive service of this type when deployed on a 5G mobile network infrastructure.

The characteristics of a network slice are for example presented in the document “A Framework for Network Slices in Networks Built from IETF Technologies” by A. Farrel et al., version 25 published on September 14, 2023.

An example of using network slices deployed in a 5G mobile infrastructure is presented in the document “A Realization of IETF Network Slices for 5G Networks Using Current IP/MPLS Technologies” by K. G. Szarkowicz et al., version 9 published on May 23, 2023.

Traditionally, traffic that can be routed within a network slice is subject to authorization (also called access control) to use the path(s) established within said slice. Such authorization is typically based on the application of traffic classification rules. These rules are generally applied by a node located at the edge of the network within which network slices have been deployed. Such an edge node is generally deployed in front of customer access (for example, an access router) or used to connect a network to other neighboring networks (for example, an edge router or edge node). For example, such an edge node may be located at the connection interface of a gateway that provides access to the Internet. This gateway is called a "Packet Gateway" for the most recent generations (4G, 5G) of mobile networks. In this case, the traffic classification function can be located at the connection interface of a "Packet Gateway" to the Internet network. An edge node can also be located at the connection interface of a mobile equipment (or "User Equipment" or UE in English) to the radio access network (or "Radio Access Network" or RAN in English), in particular so as to optimize the use of radio resources according to the type of the network slice and the profile of the traffic that it is likely to carry. A traffic profile is the set of characteristics specific to the traffic. These characteristics can reflect the sensitivity of applications to latency, transit delay or packet loss, but also usage practices, for example traffic that would only be generated over a given period (such as management traffic linked to the execution of a maintenance operation on equipment scheduled during the night).

In summary, traffic classification and admission control rules are applied at the edge of the network, in edge nodes (e.g., access router, border router). Applying traffic classification rules can be complex, as the level of granularity associated with the engineering and deployment of a network slice can be macroscopic (e.g., a network slice deployed to route traffic to the Internet), or microscopic (for example a network slice deployed for application traffic exchanged between two mobile devices).

This granularity generates an overall complexity of network slice engineering, for example a difficulty in optimizing the use of resources implemented by a network slice, by a set of network slices, or by all network slices, or a difficulty in strictly guaranteeing the isolation of traffic routed within a network slice, or even a difficulty in strictly guaranteeing the level of quality or security associated with a network slice, or even the level of availability and resilience of a given network slice, etc.

In particular, the complexity of configuring and applying traffic classification rules associated with the implementation of a given network slice evolves with the diversity of traffic, the richness of the organization of the structure that operates the network slice (for example, an accounting department, an R&D department, a production department) or the mode of use of the network slice (for example, management of traffic overloads during busy hours, principles of traffic load distribution). This complexity can be aggravated in particular by the evolution of traffic classification rules over time (for example, in the context of the deployment of a network slice for the retransmission of a sporting or cultural event, the traffic classification rules can evolve with the number and profile of users of the network slice).

In particular, there are techniques for verifying the reachability (or accessibility) of a remote device from a device connected to a network, but these techniques do not guarantee that the request and the response are routed via the same network slice. For example, an ICMP ("Internet Control Message Protocol") request of the "Echo Request" type (generally called "Ping") can be sent by a device to check whether it can connect to a remote site. However, such a request does not allow the return reachability to be verified, in particular if the path taken by the data coming from the device ("forward" traffic) differs from the path taken by the data going to the device ("return" traffic). Such an ICMP request therefore does not allow the path taken by the response (ICMP "Echo Reply") to be determined.

As such, the "forward" traffic classification rules, which allow, in particular, a path to be taken within a network slice, are unsuitable for processing "return" traffic, which is likely to take a different path if the routing is asymmetric. In particular, the return traffic may be routed within the same network slice as that used to route the “go” traffic, or within a different network slice but to which the equipment would also be connected.

The same issue affects other types of connectivity check messages (I0AM request - In-band Operations, Administration, and Maintenance, LSP Ping - Label Switched Path, etc.).

Similarly, traffic classification rules may be ineffective if the data path crosses a network that does not have network slices, or does not support a specific type of network slice chosen to route the data.

There is therefore a need for a new technique controlled by equipment and seeking to verify the reachability of said equipment from a remote site, via one or more networks which support network slices, for the routing of traffic to the equipment.

3. Statement of the invention

The invention proposes a solution seeking to meet this need, in the form of a method for verifying the accessibility of equipment for routing data to said equipment via at least one network slice, comprising:

- the reception, via at least one secure channel between the equipment and at least one control server, of information relating to at least one verification message corresponding to at least one action of “verification of the accessibility of said equipment via at least one network slice” to be executed,

- verifying the execution of said at least one action using said information.

Such a method can in particular be implemented by the equipment whose reachability is to be verified for the routing of return traffic (i.e. to the equipment) via one or more network slices.

In particular, according to this method, the equipment receives information relating to at least one verification message from a control server (in English "Probing Server"), via a secure channel. Such a control server can in particular generate at least one verification message, on the basis of instructions or guidelines transmitted by the equipment to the control server as explained below, or well known to the control server. In particular, such a verification message corresponds to at least one action of "verifying the accessibility of the equipment via at least one network slice" to be executed.

Receiving this information lets the equipment know that a process of verifying its reachability has been initiated. Thus, the equipment can verify the execution of said at least one action using said information. For example, if the equipment receives via at least one network slice a verification message corresponding to at least one action to be executed, it can verify whether the received verification message corresponds to the information relating to the verification message previously received via the secure channel. If this is the case, the accessibility of the equipment for routing data to the equipment via said at least one network slice is confirmed.

Conversely, if the equipment does not receive a verification message for all or part of the network slices subject to the current verification, or receives a verification message via at least one network slice which does not correspond to the information relating to the verification message previously received via the secure channel, the accessibility of the equipment for routing data to the equipment via at least one network slice subject to the current verification is not confirmed.

As indicated above, according to a particular embodiment, the method comprises the prior transmission by said equipment, via said secure channel, of instructions comprising at least one action of “verifying the accessibility of said equipment via at least one network slice” to be executed and possibly at least one of the following information:

- network slice identification information enabling at least one network slice or type of network slice to be tested for routing data to said equipment,

- identification information of a network segment making it possible to identify at least one relay entity to be requested to test the routing of data to said equipment.

In particular, if no network slice identification information is available, the control server may test all network slices to which the equipment is connected or to which it is authorized to connect, by transmitting at least one verification message via each of these network slices.

In a particular embodiment, the identification information of a network segment makes it possible, for example, to test the reachability of the equipment only on a local network, by transmitting at least one verification message from at least one relay entity connected to the local network. Alternatively, they make it possible to test the reachability of the equipment on a wide area network, corresponding for example to a regional backbone network, by transmitting at least one verification message from at least one relay entity connected to the wide area network. The identification information of a network segment also makes it possible to test the reachability of the equipment according to networks implementing different digital communication techniques (Wi-Fi® or 5G for example). One or more relay entities can be selected to issue the verification messages, which can be issued concurrently or sequentially by these relay entities.

In a particular embodiment, the method comprises a prior step of selecting said at least one control server taking into account a constraint on a relay entity intended to send said at least one verification message.

For example, the equipment selects a control server connected to the same network as the relay entity intended to transmit said at least one verification message. Thus, if the equipment is connected to a local network, at least one control server internal to the local network can be selected to test the reachability of the equipment on the local network. To test the reachability of the equipment on a wide area network, at least one control server external to the local network can be selected.

Note that the equipment does not need to know the identity of the relay entity directly. For example, the equipment uses information from the control server(s) to select an appropriate control server.

A control server may in particular indicate the network to which a relay entity is connected by broadcasting information such as an autonomous system identifier ("Autonomous System Number"), network domain name, etc. The equipment may apply filters according to instructions allowing it to select an appropriate control server. These filters are applied by the equipment globally or by request. Such instructions may be communicated by indicating parameters that characterize the scope of the checks, for example "test local", "test_peer" (test from one or all of the networks connected to the local network), "test_asn" (list of autonomous system identifiers), etc.

In a particular embodiment, said method comprises receiving said at least one verification message corresponding to said at least one action to be executed and said verification implements a comparison of said at least one verification message received with said information relating to said at least one corresponding verification message.

For example, a correlation can be made between the content of a verification message received by the equipment and the information relating to this verification message previously received by the equipment from said control server.

In a particular embodiment, the method comprises the transmission by said equipment of a response to said at least one verification message. Such a response may in particular be sent by the equipment when the verification message is a verification request. Such a response may be sent to the control server sending the verification message, or to the relay entity sending the verification message. In a particular embodiment, during a discovery phase or during the authorization phase, information can be exchanged between the equipment and at least one control server.

For example, the method comprises the transmission, via the secure channel, of at least one descriptive information of said equipment belonging to the group comprising:

- at least one type of network slice supported by said equipment,

- at least one identifier of a network slice supported by said equipment,

- at least one identifier of a network to which said equipment is connected.

The method may also or alternatively comprise receiving, via said secure channel, at least one piece of descriptive information from said control server belonging to the group comprising:

- at least one type of network slice supported by said control server,

- at least one identifier of a network slice supported by said control server,

- at least one identifier of a network to which said control server is connected,

- at least one indicator specifying whether said control server supports a collaborative mode with the network to which the equipment is connected,

- a list of network domain identifiers with which the control server supports collaborative mode, and the storage of said at least one descriptive information of said control server.

In another embodiment, the invention relates to equipment suitable for implementing the accessibility verification method described above. Such equipment may of course have the various characteristics relating to the accessibility verification method according to the invention, which may be combined or considered in isolation. Thus, the characteristics and advantages of this equipment are the same as those of the method and are not detailed further.

For example, such equipment is a user equipment, a CPE (Customer Premises Equipment), a service instance, a router, a server, etc.

The invention also relates to a method for managing the accessibility of equipment for routing data to said equipment, via at least one network slice, implemented by a control server, comprising:

- obtaining instructions including at least one action of “verifying the accessibility of said equipment via at least one network slice” to be executed,

- the generation of at least one verification message from said instructions, - the transmission to said equipment, via a secure channel between the equipment and said control server, of information relating to said at least one verification message.

As previously stated, such instructions may be transmitted by the equipment, or known in advance to the control server.

In particular, these instructions are used to construct at least one verification message. Verification messages may then be sent by the control server to the equipment, and/or by at least one relay entity to the equipment. In particular, separate verification messages may be generated for transmission by the same relay entity or separate relay entities.

According to a first embodiment (not relying on the participation of a network controller, nor on the participation of a relay entity), the method comprises the transmission, to the equipment, of said at least one verification message via at least one network slice or type of network slice to be tested.

The control server can thus directly transmit one or more verification messages to the equipment (for example, one verification message per network slice to be tested).

In particular, the equipment may respond to the verification message it receives from the control server, in particular if the verification message is a verification request.

In this case, the process includes:

- the receipt, from said equipment, of a response to said at least one verification message, and

- the transmission to said equipment, via the secure channel between said equipment and said control server, of information relating to said response.

In particular, if the control server transmits an error message to the equipment, the latter can restart the verification procedure to test its reachability via another network slice, for example.

According to a second embodiment (not based on the participation of a network controller, but based on the participation of at least one relay entity), the method comprises:

- the selection of at least one relay entity from the instructions,

- the transmission to said at least one relay entity of said at least one verification message (or possibly of information relating to said at least one verification message).

The control server can thus transmit one or more verification messages to the equipment via at least one relay entity (for example to test the reachability of the equipment on a network segment between the relay entity and the equipment). In particular, the equipment may respond to the verification message that it receives from a relay entity, in particular if the verification message is a verification request.

In this case, the process includes:

- receiving, from said at least one relay entity, a response to at least one verification message sent by said at least one relay entity, and

- the transmission to said equipment, via said secure channel between said equipment and said control server, of information relating to said response.

Conversely, if the relay entity does not receive a response from the equipment to a verification message, or if the relay entity receives an error code following the sending of a verification message, the relay entity can transmit an error message to the control server. The latter can then relay said error message to the equipment, and the latter can restart the verification procedure to test its reachability via another relay entity, for example.

According to a third embodiment (based on the participation of at least one network controller and at least one relay entity), the method comprises:

- the selection of at least one relay entity from said instructions,

- the selection of at least one network controller, taking into account a constraint on said at least one selected relay entity,

- the transmission, to said at least one network controller, of said at least one verification message (or possibly of information relating to said at least one verification message).

For example, the constraint on said at least one relay entity can be inferred from the verification instructions.

The control server can thus transmit one or more verification messages to the equipment via at least one network controller and at least one relay entity (for example to test the reachability of the equipment on a network segment between the relay entity and the equipment).

In particular, the equipment may respond to the verification message that it receives from a relay entity, in particular if the verification message is a verification request.

In this case, the process includes:

- receiving, from said at least one network controller, a response to at least one verification message sent by said at least one relay entity, and

- the transmission to said equipment, via said secure channel between said equipment and said control server, of information relating to said response. In another embodiment, the invention relates to a control server ("Probing Server") capable of implementing the accessibility management method described above. Such a control server may of course have the various characteristics relating to the accessibility management method according to the invention, which may be combined or considered in isolation. Thus, the characteristics and advantages of this control server are the same as those of the method and are not detailed further.

The invention further relates to a method for controlling the accessibility of equipment for routing data to said equipment, via at least one network slice, implemented by a network controller, comprising:

- receiving at least one verification message (or information relating to said at least one verification message) from a control server, said verification message corresponding to at least one action of “verifying the accessibility of said equipment via at least one network slice” to be executed,

- the transmission to at least one selected relay entity of said at least one verification message (or possibly of information relating to said at least one verification message).

According to this embodiment, the control server can select a relay entity intended to relay at least one verification message, and consequently a network controller to which the selected relay entity is connected.

In particular, the equipment may respond to the verification message it receives, in particular if the verification message is a verification request.

In this case, the method implemented by the network controller comprises receiving, from said at least one selected relay entity, information relating to a response to said at least one verification message.

In another embodiment, the invention relates to a network controller adapted to implement the accessibility control method described above. Such a network controller may have the various characteristics relating to the accessibility control method according to the invention, which may be combined or considered in isolation. Thus, the characteristics and advantages of this network controller are the same as those of the method and are not detailed further.

The invention further relates to a method for carrying out a verification of the accessibility of equipment for the routing of data to said equipment, via at least one network slice, implemented by a relay entity, comprising: - receiving at least one verification message (or information relating to said at least one verification message) from a control server, or at least one verification message (or information relating to said at least one verification message) from a network controller of the network to which said relay entity is connected, said at least one verification message corresponding to at least one action of “verifying the accessibility of said equipment via at least one network slice” to be executed by said relay entity,

- the transmission, to said equipment, of said at least one verification message.

In particular, the verification message sent by the relay entity can be constructed from information relating to said at least one verification message transmitted by the control server or the network controller.

In particular, the equipment may respond to a verification message that it receives, in particular if the verification message is a verification request.

In this case, the process implemented by the relay entity includes:

- receipt of a response to at least one verification message,

- the transmission, to said control server or said network controller, of information relating to said response.

In another embodiment, the invention relates to a relay entity adapted to implement the method for performing the accessibility verification described above. Such a relay entity may of course have the various characteristics relating to the method for performing the accessibility verification according to the invention, which may be combined or considered in isolation. Thus, the characteristics and advantages of this relay entity are the same as those of the method and are not detailed further.

For example, such a relay entity is a border router.

In a particular embodiment, secure channels are established between two entities (control server, network controller and/or relay entity).

For example, secure channels according to the various processes implement the QUIC secure transport protocol.

The implementation of a secure channel between the equipment and the control server, and possibly between two entities (control server, network controller and/or relay entity) helps to ensure the integrity of the data exchanged via this secure channel.

In a particular embodiment, said at least one verification message according to the different methods belongs to the group comprising:

- an ICMP “Echo Request”, an IOAM query,

- at least one UDP “Traceroute” packet,

- at least one LSP Ping packet,

- at least one SFC Ping packet.

In the various embodiments envisaged, at least one of said network slices may be composed of at least one local network slice deployed in at least one subnetwork (for example in an access network, a collection network, a core network, and a transit network).

The invention also relates to at least one computer program comprising instructions for implementing at least one of the methods described above, when this or these programs are executed by a processor, as well as at least one information medium readable by a computer comprising instructions of at least one computer program as mentioned above.

The method according to the invention can be implemented in various ways, in particular in wired form or in software form.

4. List of figures

Other characteristics and advantages of the invention will appear more clearly on reading the following description of a particular embodiment, given as an illustrative and non-limiting example, and the appended drawings, among which: Figure 1 illustrates an example of a communication network composed of several sub-networks; Figure 2 illustrates an example of aggregation of several services within the same network slice; Figure 3 illustrates an example of deployment of several service instances; Figure 4 represents a system in which the invention can be implemented; Figure 5A illustrates the main steps of the methods according to a first embodiment of the invention; Figure 5B illustrates the messages exchanged according to this first embodiment; Figure 6A illustrates the main steps of the methods according to a second embodiment of the invention; Figure 6B illustrates the messages exchanged according to this second embodiment; Figure 7A illustrates the main steps of the methods according to a third embodiment of the invention; Figure 7B illustrates the messages exchanged according to this third embodiment; Figure 8 illustrates an example of implementation with a control server internal to the network to which the equipment is connected; Figure 9 illustrates an example of implementation with a control server external to the network to which the equipment is connected; Figure 10 illustrates an example of implementation with a network controller; Figure 11 presents the simplified structure of the different entities according to a particular embodiment.

5. Description of an embodiment of the invention

5.1 General

Consider a communications network (possibly composed of several networks or subnetworks) that supports network slices. A network slice can be associated with other network slices to provide value-added services. For example, a service provider can rely on slices set up in different subnetworks to provide a service whose traffic is intended to be routed in the "global" network slice composed of slices deployed in the different subnetworks. This is called a "multi-domain slice" (or "stitched slices" or "hierarchical slices"). Such a network slice can indeed reflect a hierarchical structure.

For example, as illustrated in Figure 1, the SSP (Slice Service Provider) network 12 may be composed of several subnetworks 121, 122 and 123. Each subnetwork may support one or more network slices. For example, the first subnetwork 121 supports four network slices, the second subnetwork 122 supports three network slices, and the third subnetwork 123 supports four network slices. The first network slice SI. #1 161 of the communication network is for example composed of network slices SI. #3 deployed on subnetwork 121, SI. #2 deployed on subnetwork 122 and SI. #2 deployed on subnet 123. The connection interfaces between adjacent slices (“Attachment Circuits” in English) are for example managed using the mechanisms described in the document “YANG Data Models for 'Attachment Circuits'-as-a-Service (ACaaS)” by M. Boucadair et al., version 6 published on May 3, 2023.

For example, each subnetwork may be associated with a distinct domain (e.g., a communications network may consist of an access network, a backhaul network, a core network, and a transit network). Each of these domains supports network slices whose engineering and operation are characteristic of the domain (e.g., a slice deployed on a 5G mobile core network may use traffic processing and operation functions characteristic of a 5G mobile core network). Each domain (access, backhaul, core, transit, etc.) may use different technologies to realize the network slices. Thus, the creation of a network slice that extends over several domains is not conditioned by the availability or activation of the same technologies used for the creation of the slices "local" to each domain.

For example, with reference to FIG. 1, a first domain associated with the first subnet 121 sets up IPsec tunnels that are used to route traffic in the slices deployed in this domain, while a second domain associated with the second subnet 122 uses network-level virtual private network engineering ("Layer 3 VPN" or L3VPN) combined with traffic engineering mechanisms ("Traffic Engineering" or TE) to route traffic in the slices deployed in this domain, while a third domain associated with the third subnet 123 uses the resources of segment routing based on the IPv6 protocol ("Segment Routing IPv6" or SRv6) to route traffic in the slices deployed in this domain.

As another example, a network slice in a mobile network (e.g. 5G) may be based on the implementation of network slices in the following different subnetworks/segments: Radio Access Network (RAN), Core Network (CN) and Transport Network (TN).

The association of a network slice, for example a 5G network slice in the case of a latest generation mobile network, with the network slices deployed in each of the segments / subnetworks composing the 5G mobile network is carried out in the control plane and at the edge of each of the RAN, CN and TN networks. The network slice deployed in the TN network is sometimes called "IETF Network Slice".

According to the invention, no assumption is made as to the nature of the network slices deployed in a network, their number, and the "mapping" between network slices of neighboring domains (for example RAN and TN, TN and CN).

For example, the mechanisms described in the previously cited document “A Realization of IETF Network Slices for 5G Networks Using Current IP/MPLS Technologies” are implemented for the realization of network slices in an IP/MPLS network (which is an example of a transport network within the meaning of 3GPP).

It is further noted that the same network slice can be used to aggregate the traffic of one or more services. Thus, as illustrated in FIG. 2, a first service SI served by one or more service instances 21 can be provided to a first client UE1 via a network slice SI. #3 of the SSP network, a second service S2 served by one or more service instances 22 can be provided to a second client UE2 via the same network slice SI. #3 of the SSP network, a third service S3 served by one or more instances of service 23 can be provided to the second customer UE2 via the same network slice SI. #3 of the SSP network.

Additionally, a network slice may involve one or more service functions (or "Service Functions" in English, according to the terminology used by RFC7665 - "Service Function Chaining (SFC) Architecture" by J. Halpern et al. published in October 2015, or "Network Functions" such as gNB ("gNodeB") or UPF ("User Plane Function") according to the terminology used by 3GPP). A single service function may be provided by one or more service instances.

Figure 3 illustrates an example of deployment of service instances. In particular, a service instance may be hosted by the SSP (e.g., service instances 33 and 34) or within another infrastructure (e.g., service instance 35).

In a particular embodiment, service chains (SFC) can be set up in order to facilitate the routing of traffic of different natures and having different profiles for the needs of creating a network slice or within a network slice.

These service chains may notably use one or more service instances hosted by a first network. For example, the chain SFC#1 is formed by the service instances 311, 312 and 313 hosted by the SSP.

These service chains may also use one or more service instances hosted by a second network. For example, chain SFC#2 is formed by service instances 311, 312, and 313 hosted by the SSP and service instances 314 and 315 hosted by another network.

We also consider a piece of equipment connected to at least one network. A piece of equipment can be a user equipment (UE), a service instance, a CPE, a server, a router, etc. The equipment can be mobile, fixed, etc.

Applications (or application clients) can be used to access a service from a device. These applications can request specific processing via APIs exposed by the device's operating system (OS).

5.2 General principle

The general principle of the invention is based on the exchange of messages between a device and at least one dedicated control server, so as to verify the accessibility of the device via at least one network slice, more precisely when the device is the recipient of the traffic.

In particular, instructions or "control instructions" (in English "Probing CTL") can be exchanged via a secure channel between the equipment and a dedicated control server. Such instructions include in particular at least one action of "verifying the accessibility of the equipment via at least one network slice" to be executed. When this action is executed, the equipment can check whether there is a link between information relating to at least one verification message generated by the control server from the instructions, this information having been transmitted from the control server to the equipment via the secure channel, and the verification message(s) received by the equipment.

Such a procedure is hereinafter called “Slicing and tracing over LArge scale Managed networks for A La carte Communications”, or SALAMALEC, for large-scale reachability procedure via network slices.

Figure 4 illustrates an exemplary system in which the invention may be implemented.

For example, the equipment is considered to be a user equipment UE 41 (“User Equipment” in English) connected to an SSP network 42 implementing network slices, for example two network slices SI. #1 421 and SI. #2 422 (“Slice” in English).

The UE 41 equipment can optionally be connected to the SSP 42 network via an intermediate router, for example a CPE.

The service may be provided by at least one service instance, for example by two service instances SFI #1 431 and SFI #2 432. A service instance may be connected to the network 42 via a border router of the network. For example, the instance 431 is connected to the network 42 via the first border router BR 441 (“Border Router” in English), and the second instance 432 is connected to the network 42 via the second border router BR 442. The service instances are not necessarily directly connected to the border routers. They may be hosted by the SSP network 42 or within another network. At least one control server 45, also called “Probing Server” or SPS for “SALAMALEC Probing Server”, may be deployed in the network to which the UE equipment 41 is connected (SSP network 42) or in a separate network. Such a control server makes it possible in particular to assist the UE equipment 41 in the execution of the availability verification process by network slice, as explained below. In particular, such a control server can select one or more relay entities intended to relay verification messages corresponding to at least one action of “verifying the accessibility of the equipment via at least one network slice” to be executed. At least one network controller 46, also called NC for “Network Controller”, can be deployed in the network to which the equipment is connected (SSP 42) or in a separate network. It can in particular control the network to which at least one relay entity is connected. For example, the network controller 46 can control the border routers 441 and 442. We now present, in relation to figures 5A, 6A and 7A, the main steps implemented by the different entities according to an embodiment of the invention.

For example, we seek to verify the accessibility of the equipment 41 for the routing of data to this equipment 41 via at least one network slice.

At least one secure channel 50 is established between the equipment 41 and at least one control server. A control server may be connected to the network to which the equipment 41 is itself connected or be connected to a separate network. Such a channel is hereinafter called a SALAMALEC channel.

The control server, for example the SPS server 45, obtains (451) instructions comprising at least one action of “verifying the accessibility of the equipment via at least one network slice” to be executed.

In one embodiment, such instructions are known to the SPS server. For example, the SPS server has information on the conditions of attachment of the equipment 41 to the different network slices because it is connected to the same network as the equipment.

Alternatively, the equipment 41 can transmit (411) to the SPS server 45, via the secure SALAMALEC channel 50 between the equipment 41 and the SPS server 45, such instructions comprising at least one action of “verifying the accessibility of the equipment via at least one network slice” to be executed. In this case, the SPS server 45 receives the instructions transmitted via the secure channel 50 from the equipment 41.

In one embodiment, such instructions comprise at least one of the following information: network slice identification information for identifying at least one network slice or type of network slice to be tested for routing data to the equipment, network segment identification information for identifying at least one relay entity to be requested to test the routing of data to the equipment. Such a relay entity corresponds for example to an injection point, i.e. to a place where verification messages can be injected into the network, as described below.

In particular, if no network slice identification information is passed, all network slices to which the device is connected (or all network slice types) can be tested.

The SPS server 45 can then generate (452), from the instructions (received from the equipment 41 or previously known to the SPS server 45), at least one verification message corresponding to said at least one action to be executed. It is noted that different verification messages can be generated to test different network slices (or types of network slice) or different segments/relay entities.

The SPS server 45 can then transmit (453) to the equipment 41, via the secure channel 50, information relating to said at least one verification message. Such information can be the verification message itself, or information making it possible to make the link with the verification message.

The equipment can thus receive (412), via the secure channel 50, information relating to said at least one verification message, transmitted by the SPS server 45. The SPS server thus notifies the equipment of the launch of the verification operations. If necessary, the SPS server can notify the equipment of the deadline for the execution of the tests (e.g. in 30 seconds) as well as the end of the tests.

The elements exchanged between the equipment 41 and the SPS server 45 (instructions including the action(s) to be carried out, possible identification information, information relating to at least one verification message) are also called “Probing CTL”, or control instructions.

These steps can be repeated with different SPSs to which the equipment is connected.

According to a first embodiment illustrated by FIG. 5A, it is considered that the SPS server 45 can directly send a verification message, generated from the instructions, to the equipment 41. To do this, the SPS server 45 sends (456) the verification message, for example an ICMP “Echo Request” request, an I0AM request, at least one UDP “Traceroute” packet, at least one LSP Ping packet, or at least one “SFC Ping” packet to the equipment 41, via at least one network slice or a type of network slice to be tested for the routing of data to the equipment. Such a transmission is not carried out via the secure channel 50.

If the equipment 41 receives (413) the verification message, it can check (414) whether the verification message that it receives is consistent (i.e. coherent) with the information relating to said at least one verification message transmitted via the secure channel during step 453. For example, a correlation can be made between the content of a verification message received by the equipment 41 and the information relating to said at least one verification message received by the equipment 41. If this is the case, this means that the equipment can be reached via the network slice(s) or type(s) of network slice(s) tested.

Optionally, the equipment 41 can send to the SPS server 45 a response to the verification message that it has received. Information relating to the response(s) received by the SPS server can be transmitted to the equipment via the secure channel 50, for example in a response message.

The response message may include an error code if a transmission error occurs. detected or if no response is received by the SPS server after a predetermined time. Thus, if the SPS server does not receive a response from the equipment to a verification message, or if the SPS server receives an error code following the sending of a verification message, the SPS server can transmit an error message to the equipment, and the latter can restart the verification procedure to test its reachability via another SPS for example.

51 the equipment 41 does not receive the verification message (for example after a determined delay, typically after the expiration of a delay from the launch of the verification tests, of the order of 60 seconds for example), while it has received the information relating to said at least one verification message, this means that the equipment cannot be reached via the network slice(s) or type(s) of network slice tested. The equipment may, if necessary, trigger a procedure to notify its network provider of this reachability problem or reset its connection to the network slice tested in order to restore the service via one or more network slice(s) or type(s) of network slice.

Figure 5B illustrates an example of messages exchanged between a device 41 and two control servers, for example a server 51 internal to the network to which the device is connected and a server

52 external to the network to which the equipment is connected.

A secure channel 510 (respectively 520) is established between the equipment 41 and the control server 51 (respectively 52). The instructions comprising at least one action of “verifying the accessibility of the equipment via at least one network slice” to be executed, any identification information and the information relating to at least one verification message (“Probing CTL”), can be exchanged between the equipment 41 and the control server 51 via the secure channel 510, and between the equipment 41 and the control server 52 via the secure channel 520. The control instructions transmitted in the different secure channels can be different (for example to test different network slices).

The control server 51, respectively 52, can then execute the corresponding action(s), for example by sending one or more verification messages “Probing Messages” 511, respectively 521.

According to a second embodiment illustrated by FIG. 6A, it is desired that at least one verification message intended for the equipment, generated from the instructions, be sent by a relay entity.

Steps 411 and 412 implemented by the equipment 41, and 451 to 453 implemented by the SPS server 45 are similar to those described in relation to FIG. 5A and are not repeated here.

According to this embodiment, the SPS server 45 selects (454) at least one relay entity from instructions. For example, such a relay entity corresponds to an injection point of a verification message making it possible to verify the reachability of the equipment 41 on a segment located between the relay entity and the equipment 41. In particular, one or more relay entities can be used to verify the reachability of the equipment 41 on a local network, on a regional backbone network, etc. In the example illustrated, the selected relay entity is for example the border router 441 or all the border routers of a network.

A network controller may also be selected (455) by considering a constraint on the selected relay entity. For example, the network controller of the network to which the selected relay entity is connected is selected.

In the illustrated example, the selected network controller is for example the NC 46 network controller.

A channel 61, for example a secure channel, is established between the selected network controller (for example NC 46) and the SPS server 45, and a channel 62, for example a secure channel, is established between the selected network controller (for example NC 46) and the selected relay entity (for example BR 441). At least one verification message (or information relating to said at least one verification message) can then be transmitted (456') from the SPS server 45 to the network controller 46 via the channel 61. Once said at least one verification message has been received (461) by the network controller 46, the latter can send said at least one verification message (or information relating to said at least one verification message) to the border router 441, via the channel 62.

The verification message (or information relating to said at least one verification message) can thus be received (4411) by said border router 441 (i.e. by at least one relay entity).

The border router 441 can then send (4412) the verification message (possibly after constructing said verification message from said information relating to said at least one verification message), for example an ICMP “Echo Request” request, an I0AM request, at least one UDP “Traceroute” packet, at least one LSP Ping packet, or at least one SFC Ping packet, to the equipment 41, via at least one network slice or a type of network slice to be tested for the routing of data from the border router 441 to the equipment 41.

If the equipment 41 receives (413') the verification message, it can check (414') whether the content of the verification message that it has received is consistent (i.e. coherent) with the information relating to said at least one verification message transmitted via the secure channel 50 during step 453. For example, a correlation can be made between the content of the verification message received by the equipment 41 and the information relating to said at least one verification message received by the equipment 41 from the SPS server 45. If this is the case, this means that the equipment 41 can be reached from the relay entity 441 via the network slice(s) or type(s) of network slice tested.

Optionally, the equipment 41 can send to the relay entity 441 a response to the verification message that it has received. Information relating to the response received by the relay entity 441 can be transmitted to the network controller 46 via the channel 62. The information received by the network controller 46 can be transmitted to the SPS server 45 via the channel 61. The information received by the SPS server can be transmitted to the equipment 41 via the secure channel 50, for example in a response message. The response message can in particular include an error code if a transmission error is detected or if no response is received by the relay entity after a predetermined time. Thus, in the absence of reception by the relay entity of a response from the equipment to a verification message, or upon reception by the relay entity of an error code following the sending of a verification message, the relay entity can transmit an error message to the SPS server 45, directly or via the network controller 46. The SPS server 45 can then relay said error message to the equipment, and the latter can restart the verification procedure to test its reachability via another SPS server or the same SPS server but via another relay entity for example.

If the equipment 41 does not receive the verification message (for example after a determined period, typically after the expiration of a period from the launch of the verification tests, of the order of 60 seconds for example), while it has received the information relating to said at least one verification message, this means that the equipment 41 cannot be reached from the relay entity 441 via the network slice(s) or type(s) of network slice tested. Note that if verification messages have been sent by the SPS server via all the interconnection points (ASBR routers (“Autonomous System Border Routers”), typically) of a network, then this means that the equipment 41 cannot be reached via the network slice(s) or type(s) of network slice tested.

Figure 6B illustrates an example of messages exchanged between a device 41, at least one control server, for example the SPS server 45, at least one network controller, for example the network controller 46, and at least one relay entity, for example the border router 441.

As indicated previously, a secure channel 50 is established between the equipment 41 and the SPS server 45. A channel 61, for example a secure channel, is also established between the SPS server 45 and the network controller 46. Finally, a channel 62, for example a secure channel, is established between the network controller 46 and the border router 441.

Instructions including at least one action of “checking the accessibility of the equipment via at least one network slice” to be executed, the possible identification information and the information relating to at least one verification message (“Probing CTL”) can be exchanged between the equipment 41 and the SPS server 45 via the secure channel 50. The verification message(s) generated from these instructions can be transmitted to the network controller 46 via the channel 61, then to the border router 441 via the channel 62. It is noted that different verification messages can be generated for the different relay entities.

The border router 441 can then perform the corresponding action(s), for example by sending one or more “Probing Messages” 63.

According to a third embodiment illustrated by FIG. 7A, it is again desired that at least one verification message intended for the equipment 41, generated from the instructions, be sent by a relay entity.

Steps 411 and 412 implemented by the equipment, and 451 to 453 implemented by the SPS server 45 are similar to those described in relation to FIG. 5A and are not repeated here. According to this third embodiment, a control server can interface directly with at least one relay entity, without going through a network controller.

According to this embodiment, the SPS server 45 selects (454') at least one relay entity from the instructions. In the illustrated example, the selected relay entity is for example the border router 441.

A channel 71, for example a secure channel, is established between at least one selected relay entity, for example the border router 441, and the SPS server 45.

At least one verification message (or information relating to said at least one verification message) may then be transmitted (456") from the SPS server 45 to the border router 441 via channel 71.

Once the verification message has been received (4411') by the border router 441 (i.e. by at least one relay entity), the border router 441 can then send (4412 ¹ ) the verification message (possibly constructed from information relating to said at least one verification message), for example an ICMP "Echo Request" request, an I0AM request, at least one UDP "Traceroute" packet, at least one LSP Ping packet, or at least one SFC Ping packet, to the equipment 41, via at least one network slice or type of network slice to be tested for the routing of data from the border router 441 to the equipment 41.

If the equipment 41 receives (413') the verification message, it can check (414") whether the content of said verification message that it receives is consistent (i.e. coherent) with the information relating to said at least one verification message transmitted via the secure channel 50 during step 453. As already indicated, a correlation can be made between the content of the verification message received by the equipment 41 and the information relating to said at least one verification message received by the equipment 41. If this is the case, this means that the equipment can be reached from the relay entity via the network slice(s) or type(s) of network slice(s) tested.

Optionally, the equipment 41 can send to the relay entity a response to the verification message that it has received. Information relating to the response received by the relay entity can be transmitted to the SPS server 45 via the channel 71. The information received by the SPS server can be transmitted to the equipment 41 via the secure channel 50, for example in a response message.

The response message may in particular include an error code if a transmission error is detected or if no response is received after a predetermined time. Thus, in the absence of reception by the relay entity of a response from the equipment to a verification message, or upon reception by the relay entity of an error code following the sending of a verification message, the relay entity may transmit an error message to the SPS server 45. The SPS server 45 may then relay said error message to the equipment, and the latter may restart the verification procedure to test its reachability via another relay entity or via another SPS server for example.

If the equipment 41 does not receive the verification message (for example after a determined delay, typically after the expiry of a delay from the launch of the tests, of the order of 60 seconds for example), while it has received the information relating to said at least one verification message, this means that the equipment 41 cannot be reached from the relay entity via the network slice(s) or type(s) of network slice(s) tested.

Figure 7B illustrates an example of messages exchanged between a device 41, at least one control server, for example the SPS server 45, and at least one relay entity, for example the border router 441.

As previously indicated, a secure channel 50 is established between the equipment 41 and the SPS server 45. A channel 71, for example a secure channel, is also established between the SPS server 45 and the border router 441.

The instructions comprising at least one action of “verifying the accessibility of the equipment via at least one network slice” to be executed, any identification information and the information relating to at least one verification message (“Probing CTL”) can be exchanged between the equipment 41 and the SPS server 45 via the secure channel 50. The verification message(s) generated from these instructions can be transmitted to the border router 441 via the channel 71. It is noted that different verification messages can be generated for the same relay entity or for the different relay entities. The border router 441 can then perform the corresponding action(s), for example by sending one or more “Probing Messages” 72.

5.3 Implementation example

An example of implementation of the invention is now presented, according to which the different secure channels implement a secure transport protocol such as the QUIC protocol (as described in the RFC 9000 standard). In other examples, at least one secure channel can implement a secure application protocol such as the CoAP protocol (in English "Constrained Application Protocol", as described in the RFC 7252 standard) on DTLS (in English "Datagram Transport Layer Security", as described in the RFC 9147 standard), or the PCP protocol (in English "Port Control Protocol", as described in the RFC 6887 standard), etc.

According to the example described below, a verification message is for example a verification request encapsulated in a QUIC frame called "PROBING_REQUEST". A response to this request can be encapsulated in a QUIC frame called "PROBING_REPLY".

5.3.1 Equipment

In this example, the equipment for which the return traffic reachability is to be checked is considered to be a user equipment. In other embodiments, such equipment may be a CPE, a service instance, a server, a router, etc.

The equipment according to this exemplary implementation is connected to at least one slice supported by a network. For example, the equipment maintains at least one of the following descriptive information for at least one of the slices to which it is connected: a network slice type (“Slice Type” or ST): this parameter can be chosen so that it can be interpreted in the same way by the different SSPs that provide this type of slice. Standardized or specific types (for example, according to over-the-counter agreements established between different SSPs) can be envisaged. For example, the ST parameter can be obtained by an equipment when it connects to a network slice provided by an SSP or by configuration (in the case where the equipment is a service instance, for example). In a particular embodiment, several types of slices can be associated with the same network slice. This is particularly useful when the same network slice is designed to aggregate several slices deployed in different subnets (“hierarchical slices”). a network slice identifier (“Slice Identifier” or SID). This parameter can be obtained by a device when connecting to a network slice provided by an SSP or by configuration (in the case where the device is a service instance, for example). a network identifier ("Network Identifier" or NID). This parameter can be used to determine whether two entities are connected to the same network. In this case, it will be possible to use the network slice identifier (SID) to mark packets for a connection routed through the network slice identified by the SID. The NID can also be useful in certain cases to facilitate correlation between the SIDs of the source and destination devices. For example, this parameter can be obtained by a device when it connects to a network slice provided by an SSP or by configuration (in the case where the device is a service instance, for example).

5.3.2 Control Servers

In order to verify the accessibility of a device via at least one network slice for routing return traffic (i.e. to the device), at least one dedicated SPS control server (“SALAMALEC Probing server”) is deployed, in the network to which the device is connected or in a separate network.

Note that an SPS control server can be managed by a SALAMALEC Probing Provider (SPP).

An SPP verification service provider can negotiate with an SSP of services based on network slices to activate the SALAMALEC procedure. A dedicated API can be used for this purpose, such as the "Network Exposure Function" (NEF) API. This API allows, for example, to register a list of SPS servers authorized to contact a network controller (or NC, for example an SDN controller). Such a network controller can notably contact different relay entities to verify the reachability of a device for routing data via at least one network slice between the relay entity(ies) and the device. Such a relay entity therefore corresponds to a specific injection point, i.e. a place where verification messages can be injected into the network (for example to test all or part of the edge nodes of a local network, a regional network, or an interconnection link).

Said API can also be used to communicate to the SPP provider descriptive information of at least one network controller, such as the reachability information of the network controller, in particular. The network controller can then be responsible for relaying the verification messages intended for the equipment to negotiated passage points (for example all or part of the ASBR type routers). For example, at least one IP address and authentication information of a network controller are exposed to the SPP provider. The latter provides this information to at least one SPS server. Similarly, network identification information can be provided to at least one SPS server (for example, a network identifier NID or address ranges). In the following, it is assumed that the NID is used. Alternatively, an SPS server may interface directly with a relay entity.

5.3.3 Discovery or authorization phase

In the first phase, the device discovers one or more SPS servers. An SPS server can be announced using the DNS infrastructure, a web page, explicit configuration, etc.

Upon discovery of an SPS server, the device establishes a SALAMALEC channel with the SPS server, for example using a QUIC connection. As mentioned, however, other protocols can be considered for establishing a secure channel.

New QUIC frames can be defined to exchange control instructions (“Probing CTL”) between the equipment and at least one SPS server.

For example, such frames are:

SLICE_TYPE: A SLICE_TYPE frame specifies the type(s) of network slices supported by a device or SPS server. The SLICE_TYPE frame can also be used to specify the type of network slices to be tested to verify the accessibility of a device. For example, a value of "0" indicates that the accessibility of the device can be tested for all types of network slices.

SLICEJD: A SLICEJD frame provides the identifier(s) of the network slices supported by a device or an SPS server. The SLICEJD frame can also be used to specify which network slices to test to verify the accessibility of a device. For example, the value "0" indicates that the accessibility of the device can be tested for all network slices known to the SPS server.

NID: An NID frame provides the identifier(s) of the networks to which the equipment or SPS server is connected. The NID frame can also be used to specify the network hosting the network slices to be tested to verify the accessibility of a piece of equipment.

COMO: A COMO frame indicates whether the SPS server supports a collaborative mode (designated by COMO) with the network to which the equipment is connected; in other words, such a frame indicates that a procedure allowing the SPS server to control the injection points of verification messages has been implemented.

PROBING_REQUEST: A PROBING_REQUEST frame can contain a verification message. For example, a PROBING_REQUEST frame encapsulates a verification request (“Request”). This PROBING_QUEST frame can be decapsulated, and the verification request sent by a relay entity, for example (a router at the edge of the network). PROBING_REPLY: A PROBING_REPLY frame can carry a response message. For example, For example, a PROBING_REPLY frame encapsulates a response (“Reply”). This response can be encapsulated by a relay entity, for example.

For example, the structure of a PROBING_REQUEST frame is as follows:

PROBING_REQUEST Frame {

Type (i),

Request_type (i),

Request,

} with :

Type (i): A unique identifier of the PROBING_REQUEST frame.

Request_type (i): The type of the encapsulated probe request. For example, the following values can be defined: 0 (ICMP), 1 (UDP), 2 (IOAM), 3 (LSP Ping), ... The "Request_type (i)" information is optional, especially if a default type is defined (for example, all probe requests are of type ICMP "Echo Request").

Request: the verification request corresponding to at least one action to be executed. Advantageously, the verification request also indicates the destination address of at least one relay entity to be requested to test the routing of data to said equipment and possibly a port number. An example of an ICMPv6 request is: (Dst@: 2001:db8 ::2 ICMPv6 126 Echo Request id=0xl234, seq=l, hop limit=64).

An example of a "PROBING_REQUEST" frame format that encapsulates an ICMP-type request is provided below:

Network slice metadata includes information about network slices. These information can be used by a node to mark data packets, making it easier to classify a verification request to unambiguously associate it with a given slice. The description of the other fields is similar to that documented in the standards RFC 792 for ICMPv4 (“Internet Control Message Protocol”, J. Postel, September 1981) and RFC 4443 for ICMPv6 (“Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification”, A. Conta et al., March 2006).

An example of a "PROBING_REQUEST" frame format that encapsulates an I0AM type request is provided below:

The description of the I0AM fields is identical to that described in RFC 9452 (“Network Service Header (NSH) Encapsulation for In Situ OAM (I0AM) Data”, F. Brockners et al., August 2023) and RFC 9197 (“Data Fields for In Situ Operations, Administration, and Maintenance (I0AM)”, F. Brockners et al., May 2022).

The verification request ("Request") encapsulated in a "PROBING_REQUEST" frame can be an ICMP message (for example an ICMP "Echo Request" message) or any other message allowing to verify if the traffic classification rules at the network ingress are correctly configured to associate a given traffic with a slice.

For example, the verification request belongs to the group including:

- an ICMP “Echo Request”,

- an I0AM request,

- at least one UDP “Traceroute” packet,

- at least one LSP Ping packet,

- at least one SFC Ping packet.

Such a verification request can also be used by the service provider using SSP network slices to enable it to verify the traffic classification rules it has implemented.

A response message may be generated in response to a verification request.

The structure of a PROBING_REPLY frame is for example as follows: PROBING_ REPLY Frame {

Type (i),

Request_type (i),

Reply,

} with :

Type (i) and Request_type (i) as defined previously in relation to the PROBING-REQUEST frame

Reply: the response to the verification request.

Thus, during the authorization phase, different messages can be exchanged between the equipment and at least one SPS server, on the secure channel established between the equipment and the SPS server in question. These messages allow in particular the SPS server to obtain at least one descriptive information of the equipment belonging to the group including:

- at least one type of network slice supported by the equipment (ST),

- at least one identifier of a network slice supported by the equipment (SID),

- at least one identifier of a network to which the equipment is connected (NID).

These messages also allow the equipment to obtain at least one descriptive information from the SPS server belonging to the group including:

- at least one type of network slice supported by the SPS server (ST),

- at least one identifier of a network slice supported by the SPS server (SID),

- at least one identifier of a network to which the SPS server is connected (NID),

- at least one indicator specifying whether the SPS server supports a collaborative mode with the network

SSP (COMO),

- a list of network domain identifiers with which the SPS server supports COMO collaborative mode.

At the end of these exchanges, the equipment can record the descriptive information of the SPS server(s). In particular, the network identifier allows the equipment to identify the SPS servers hosted by the same network as the one to which the equipment is connected.

The equipment can then close the secure connection, by closing the SALAMALEC channel.

5.3.4 Verification of reachability

During a second phase, the equipment can check its reachability via a given network slice from a relay entity connected to the same network as that to which the equipment is connected, or connected to a different network, for example the Internet network. The device may optionally select the SPS server(s) to be used to test its reachability. For example, the device may retain only the SPS servers internal to the network to which the device is connected, or only the SPS servers external to the network to which the device is connected, or even the SPS servers that support collaborative mode, as indicated in the COMO attribute. This selection may optionally be made by the device user, for example according to a selection confirmation request, according to a list of SPS servers to be checked using geographical indications, etc.

Note that the equipment can concurrently or sequentially request several SPS servers selected during the previous step.

The equipment can then establish a SALAMALEC channel with each of the SPS servers that it has selected (or with all of the SPS servers that it discovered during the authorization phase if the equipment does not implement a process for selecting SPS servers).

The equipment can then transmit to the SPS servers, via the various SALAMALEC channels, instructions comprising at least one action/command to be executed by the SPS server or by at least one relay entity (for example, generation of an ICMP “Echo Request” request, UDP “Traceroute” packets, LSP Ping packets, SFC Ping packets).

Alternatively, the SPS server has these instructions directly available.

These instructions can also identify the network slice(s), or network slice type, to be tested. For example, a device can request an SPS to perform checks for all or some of the available network slices. To do this, the device uses appropriate QUIC frames, such as SLICEJD and PROBING_REQUEST frames. Alternatively, no network slice is specified. In this case, the SPS can perform checks for all available network slices.

The SPS server can in particular extract from these instructions the action(s)/command(s) to be executed to check the reachability of the equipment, network slice identification information making it possible to identify at least one network slice or a type of network slice to be tested, network segment identification information making it possible to identify at least one relay entity to be requested to test the data routing (for example the destination address corresponding to a relay entity to be requested).

In a first embodiment, corresponding to that illustrated by Figures 5A and 5B, it is considered that the verification requests can be issued directly by the SPS server.

In this case, the SPS server can send at least one verification request (ICMP “Echo Request”, I0AM, etc.) to the equipment, generated from the instructions received from the equipment or according to logic specific to the SPS server. Such a verification request is also called a “probing” request.

The response(s) received by the SPS server can be transmitted to the equipment in a response message (for example in a PROBING_REPLY frame).

In a second embodiment, corresponding to that illustrated by Figures 6A and 6B, it is considered that the verification requests are constrained and must be issued from another injection point corresponding to a relay entity, according to instructions formulated by a device, its user or by an SSP. For example, such a relay entity can be identified by the SPS server from a destination address present in the instructions transmitted by the device.

Upon receipt of the instructions, the SPS server may in particular generate one or more verification requests (“Request”) corresponding to one or more actions/commands to be executed. Such verification requests may be encapsulated in at least one PROBING_REQUEST frame.

The SPS server may forward the PROBING_REQUEST frame(s) to at least one relay entity selected from the instructions, either directly or through a network controller. For example, the SPS server may forward the PROBING_REQUEST frame(s) to the network controller connected to the same network as the device (e.g., identified by the same NID as the network to which the device is connected), or to the network controller of a network separate from the network to which the device is connected (e.g., identified by a different NID than the network to which the device is connected).

If a network check occurs, the PROBING_REQUEST frame(s) are transmitted via a secure channel established between the SPS server and the network controller.

One or more relay entities, for example a border router (BR), may be requested by the network controller to execute verification requests as instructed by an SPS server.

Thus, a network controller receiving a PROBING_REQUEST frame can forward the PROBING_REQUEST frame to one or more relay entities (for example, identified by the destination address present in the "Request" verification request of the PROBING_REQUEST frame). Such exchanges are carried out over a secure channel established between the network controller and the relay entity.

A relay entity receiving a PROBING_REQUEST frame can decapsulate the PROBING_REQUEST frame to retrieve the verification request. The verification request can then be sent by the relay entity (a router at the edge of the network, for example). Such a relay entity can notably use its own source address to send the verification request(s). verification.

The response(s) received by the relay entity can be forwarded to the network controller in a PROBING_REPLY frame. The network controller can forward the PROBING_REPLY frame to the SPS server, which can in turn forward it to the device.

In a third embodiment, corresponding to that illustrated by Figures 7A and 7B, it is also considered that the verification requests are constrained and must be issued from another injection point corresponding to a relay entity. According to this embodiment, the SPS server can in particular generate one or more verification requests (“Request”) and encapsulate them in at least one PROBING_REQUEST frame, for transmission to a relay entity identified for example from the destination address present in the verification request. According to this embodiment, the SPS server can communicate directly with the relay entities, without requiring the intervention of a network controller.

In these different embodiments, the SPS server can notify the equipment of the launch of the verification operations or the deadline for such a verification (e.g., deferred mode). To do this, the SPS server can in particular communicate to the equipment, via the secure channel, information relating to the verification requests that it has generated. A deadline can optionally be communicated to control the time beyond which the equipment terminates the verification step.

The equipment may, if necessary, perform the necessary operations to enable the processing of received verification requests (for example, configure a firewall to accept the routing of PROBING_REQUEST frames or instantiate a state in a "Carrier-Grade NAT" CGN).

If the device receives verification requests sent by the SPS server or by a relay entity (for example, if it receives an ICMP Echo Request encapsulated in a PROBING_REQUEST frame) and these verification requests match the information received via the secure channel established between the SPS server and the device, the latter concludes that the return path via one or more network slices is operational. The verification message may include information on the path taken by the response within the network slice (intra-slice) if this function has been enabled by the SPS server.

If no verification request sent by the SPS server or by a relay entity is received by the equipment (for example if the equipment does not receive the ICMP verification request "Echo Request"), typically after expiration of a given deadline, the SPS server can communicate to the equipment the error message that it received if any. For example, the SPS server receives a response following the verification request that it sent. Such a response can be a message ICMP error message that is sent by a router on the path of the request. The SPS server can encapsulate the received response in a response message (PROBING_REPLY frame), and transmit this response message to the device. Alternatively, the relay entity receives a response to the verification request that it has issued. The relay entity can encapsulate the received response in a response message (PROBING_REPLY frame), and transmit the response message to the SPS server (directly or via a network controller) which can in turn transmit this response message to the device.

In particular, the error message encapsulated in a PROBING_REPLY frame transmitted to the equipment allows the latter to detect and identify the reachability problem within a network slice.

As examples, Figures 8 to 10 illustrate the execution of a SALAMALEC verification procedure according to these different embodiments.

Applications (or application clients) can be used to access a service from a device. These applications can request, via APIs exposed by the device's operating system ("OS"), specific processing. For example, an application APP1 uses the device's API to check the device's reachability via a network slice Sl#1 and an application APP2 uses the device's API to check the device's reachability via a network slice Sl#2.

According to the example illustrated by Figure 8, we consider an SPS server 85 internal to the SSP network 82 to which a device 81 is connected. The device 81 requests the SPS server 85 to execute a verification procedure not involving a network controller. Figure 8 illustrates an example where reachability via a network slice is confirmed.

Thus, the device 81 sends instructions to the SPS server 85. The latter generates a verification request and sends to the device 81 information relating to the verification request via a secure channel (for example in a PROBING_REQUEST frame encapsulating the verification request). The SPS server 85 also executes the action corresponding to the verification request, for example by sending an ICMP “Echo Request” request. According to the example illustrated, the device 81 receives the ICMP “Echo Request” request via the border router BR 841. The device 81 can compare the received ICMP “Echo Request” request and the information relating to the verification request. If this information is identical or related, the reachability is confirmed via the network slice Sl#l 821.

According to the example illustrated by figure 9, we consider an SPS server 95 external to the SSP network 92 to which a device 91 is connected. The device 91 requests the SPS server 95 to execute a verification procedure not involving a network controller. Figure 9 illustrates an example where reachability via a network slice is not confirmed.

Thus, the device 91 sends instructions to the SPS server 95, via a border router 942. The SPS server 95 generates a verification request and sends to the device 91 information relating to the verification request via a secure channel (for example in a PROBING_REQUEST frame encapsulating the verification request). The SPS server 95 also executes the action corresponding to the verification request, for example by sending an ICMP “Echo Request” request. According to the example illustrated, the device 91 does not receive the ICMP “Echo Request” request, while it expects to receive such a request, as specified in the information relating to the verification request. The ICMP “Echo Request” request is in this example filtered by the border router 942 and is not transmitted to the device 91. The failure of reachability is for example linked to the inadequacy of the traffic classification rules.

According to the example illustrated by Figure 10, we consider an SPS server 105 internal to the SSP network 102 to which a device 101 is connected. The device 101 requests the SPS server 105 to execute a verification procedure involving a network controller 106. Figure 10 illustrates an example where the reachability via a network slice is confirmed from one or more border routers (for example a first border router 1041 and a second border router 1042). Thus, the device 101 sends instructions to the SPS server 105, via the first border router 1041. The SPS server 105 generates a verification request and sends to the device 101 information relating to the verification request (for example a PROBING_REQUEST frame encapsulating the verification request). The SPS server 105 also sends the verification request or PROBING_REQUEST frame to the network controller 106. The latter sends it to the second border router 1042.

The second border router 1042 may decapsulate the PROBING_REQUEST frame to extract the probe request. The second border router 1042 may then perform the action corresponding to the probe request, for example, by issuing an ICMP Echo Request.

According to the illustrated example, the device 101 receives the ICMP Echo Request via the border router BR 1041. The device 101 can compare the received ICMP Echo Request with the previously received information relating to the verification request. If this information is identical or correlated, the reachability of the device is confirmed via the tested network slice Sl#2 1022.

5.4 Variants Various examples have been described above in which the equipment is a user equipment. In other embodiments, implementing similar steps, the equipment may be a CPE, a service instance, a server, a router, etc.

In particular, the SALAMALEC procedure can be triggered from a device connected to the network via a CPE. The same steps as those described previously are implemented by the device. However, the device can in this case instruct the CPE not to filter verification messages sent from an SPS server. To do this, the device can use a configuration interface of the CPE or invoke an ACL ("Access Control List") management protocol such as PCP or RESTCONF, as described in RFC8040 ("RESTCONF Protocol").

A. Bierman et al. January 2017) or RFC8519 (“YANG Data Model for Network Access Control Lists (ACLs)”, M. Jethanandani et al., March 2019).

We have also described the case where a control server is a dedicated server. Alternatively, the SPS server can be embedded in a server that provides a service. The verification messages can then be encapsulated in the messages that are part of the service (i.e., service invocation messages such as http or SIP messages).

5.5 Simplified structure of corresponding entities

Finally, in relation to Figure 11, we present the simplified structures of an entity, for example a piece of equipment, a control server, a network controller, or a relay entity according to an embodiment of the invention.

As illustrated by Figure 11, such an entity comprises at least one memory 111 comprising a buffer memory, at least one processing unit 112, equipped for example with a programmable computing machine or a dedicated computing machine, for example a processor P, and controlled by the computer program 113, implementing steps of at least one method according to at least one embodiment of the invention.

Upon initialization, the code instructions of the computer program 113 are for example loaded into a RAM memory before being executed by the processor of the processing unit 112.

If the entity is a piece of equipment, the processor of the processing unit 112 implements steps of the method for verifying the accessibility of the equipment for routing data to the equipment via at least one network slice, described previously, according to the instructions of the computer program 113, for:

- receive, via at least one secure channel between the equipment and at least one control server, information relating to at least one verification message corresponding to at least one action of verifying the accessibility of said equipment via at least one network slice to be executed, - verify the execution of said at least one action using said information.

If the entity is a control server, the processor of the processing unit 112 implements steps of the method for managing the accessibility of a device for routing data to the device via at least one network slice, described previously, according to the instructions of the computer program 113, for:

- obtain instructions including at least one action of verifying the accessibility of said equipment via at least one network slice to be executed,

- generate at least one verification message from said instructions,

- transmit to said equipment, via a secure channel between said equipment and said control server, information relating to said at least one verification message.

If the entity is a network controller, the processor of the processing unit 112 implements steps of the method for controlling the accessibility of a device for routing data to said device, via at least one network slice, described previously, according to the instructions of the computer program 113, for:

- receive at least one verification message from a control server, said at least one verification message corresponding to at least one action of verifying the accessibility of said equipment via at least one network slice to be executed,

- transmitting to at least one selected relay entity said at least one verification message. If the entity is a relay entity, the processor of the processing unit 112 implements steps of the method for executing a verification of the accessibility of a device for the routing of data to said device via at least one network slice, described previously, according to the instructions of the computer program 113, for:

- receive at least one verification message from a control server or from a network controller of the network to which said relay entity is connected, said at least one verification message corresponding to at least one action of verifying the accessibility of said equipment, via at least one network slice, to be executed by said relay entity, transmit, to said equipment, said at least one verification message.

Claims

1. Method for verifying the accessibility of equipment for routing data to said equipment via at least one network slice, comprising: - receiving (412), via at least one secure channel (50) between said equipment and at least one control server (45), information relating to at least one verification message corresponding to at least one action of verifying the accessibility of said equipment (41) via at least one network slice to be executed, - verifying (414) the execution of said at least one action using said information. 2. Method according to claim 1, characterized in that it also comprises the transmission (411), via said secure channel (50), of instructions comprising at least one action of verifying the accessibility of said equipment via at least one network slice to be executed, and at least one of the following information: - network slice identification information enabling at least one network slice or type of network slice to be tested for routing data to said equipment, - identification information of a network segment making it possible to identify at least one relay entity to be requested to test the routing of data to said equipment. 3. Method according to any one of claims 1 and 2, characterized in that it comprises a prior step of selecting said at least one control server taking into account a constraint on a relay entity intended to send said at least one verification message. 4. Method according to any one of claims 1 to 3, characterized in that it comprises the reception (413) of said at least one verification message corresponding to said at least one action to be executed and in that said verification implements a comparison of said at least one verification message received with said information relating to said at least one corresponding verification message. 5. Method for managing the accessibility of equipment for routing data to said equipment, via at least one network slice, implemented by a control server, comprising: - obtaining (451) instructions comprising at least one action of verifying the accessibility of said equipment via at least one network slice to be executed, - the generation (452) of at least one verification message from said instructions, - the transmission (453) to said equipment, via a secure channel (50) between said equipment and said control server, of information relating to said at least one verification message. 6. Method according to claim 5, characterized in that said method comprises the transmission (456), to said equipment, of said at least one verification message via at least one network slice or type of network slice to be tested. 7. Method according to claim 5, characterized in that said method comprises: - the selection (454') of at least one relay entity from said instructions, - the transmission (456") to said at least one relay entity of said at least one verification message. 8. Method according to claim 5, characterized in that said method comprises: - the selection (454) of at least one relay entity from said instructions, - the selection (455) of at least one network controller, taking into account a constraint on said at least one relay entity to be selected, - the transmission (456'), to said at least one network controller, of said at least one verification message. 9. Method for carrying out a verification of the accessibility of equipment for the routing of data to said equipment, via at least one network slice, implemented by a relay entity, comprising: - receiving (4411) at least one verification message from a control server, directly or via a network controller of the network to which said relay entity is connected, said at least one verification message corresponding to at least one action of verifying the accessibility of said equipment, via at least one network slice, to be executed by said relay entity, - the execution of said at least one action of verifying the accessibility of said equipment comprising the transmission (4412), to said equipment, of said at least one verification message. 10. Method according to any one of claims 1 to 9, characterized in that said at least one verification message belongs to the group comprising: - an ICMP “Echo Request”, - an I0AM request, - at least one UDP “Traceroute” packet, - at least one LSP Ping packet, - at least one SFC Ping packet. 11. Method according to any one of claims 1 to 10, characterized in that said secure channel implements a QUIC secure transport protocol. 12. Equipment capable of verifying its accessibility for routing data to its destination via at least one network slice, comprising at least one processor configured to: - receive, via at least one secure channel between the equipment and at least one control server, information relating to at least one verification message corresponding to at least one action of verifying the accessibility of said equipment via at least one network slice to be executed, - verify the execution of said at least one action using said information. 13. Control server capable of managing the accessibility of equipment for the routing of data to said equipment, via at least one network slice, comprising at least one processor configured to: - obtain instructions including at least one action of verifying the accessibility of said equipment via at least one network slice to be executed, - generate at least one verification message from said instructions, - transmit to said equipment, via a secure channel between said equipment and said control server, information relating to said at least one verification message. 14. Relay entity capable of carrying out a verification of the accessibility of equipment for the routing of data to said equipment, via at least one network slice, comprising at least one processor configured to: - receive at least one verification message from a control server directly or via a network controller of the network to which said relay entity is connected, said at least one verification message corresponding to at least one action of verifying the accessibility of said equipment, via at least one network slice, to be executed by said relay entity, - execute said at least one action of verifying the accessibility of said equipment by transmitting, to said equipment, said at least one verification message.