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

Abstract

Methods for verifying, managing, controlling, and executing a verification of the accessibility of equipment, equipment, control server, network controller, relay entity, and corresponding computer program. The invention relates to a method for verifying the accessibility of equipment for the routing of data to said equipment via at least one network segment, 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 for verifying the accessibility of said equipment (41) via at least one network segment to be executed; and verifying (414) the execution of said at least one action using said information. Figure for the abstract: Figure 4

Description

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

[0001] 1. Technical field

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

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

[0004] 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.

[0005] 2. Prior art

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

[0007] The characteristics of a network slice are mainly expressed in terms of capacity (bandwidth) and quality of service (for example latency or unidirectional transit time), or even security (for example preservation of the confidentiality of information transmitted within the VPN by using encryption techniques) and service functions (“Service Functions (SF)”).

[0008] As an illustration, the 3GPP organization has defined different types of network slices according to their characteristics, for example: - a first type of network slices allowing the provision of an improved mobile broadband service (“enhanced Mobile BroadBand” or eMBB in English); - a second type of network slices enabling a service to be offered 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 the provision of an ultra-reliable, low-latency communications service (“Ultra Reliable Low Latency Communications” or URLLC in English).

[0009] 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 it is deployed on a 5G mobile network infrastructure.

[0010] 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.

[0011] 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 KG Szarkowicz et al., version 9 published on May 23, 2023.

[0012] Conventionally, traffic that may be routed within a network slice is subject to authorization (also called access control) to take 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 client 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 device (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 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).

[0013] In summary, traffic classification and admission control rules are applied at the edge of the network, in the edge nodes (access router, border router for example).

[0014] The application of traffic classification rules can be complex, because the level of granularity associated with the engineering and deployment of a network slice can be macroscopic (for example, a network slice deployed to route traffic destined for the Internet), or microscopic (for example, a network slice deployed for application traffic exchanged between two mobile devices).

[0015] This granularity generates an overall complexity of the engineering of network slices, for example a difficulty in optimizing the use of the resources implemented by a network slice, by a set of network slices, or by all the network slices, or a difficulty in strictly guaranteeing the isolation of the 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.

[0016] In particular, the complexity of the configuration and application of 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 even the mode of use of the network slice (for example, management of traffic overloads during busy hours, principles of distribution of the traffic load). This complexity can in particular be aggravated by the evolution of the 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 the users of the network slice).

[0017] 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 verify whether it can connect to a remote site. On the other hand, such a request does not make it possible to verify reachability in the return direction, 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 make it possible to determine the path taken by the response (ICMP “Echo Reply”).

[0018] In this respect, the rules for classifying “forward” traffic, which in particular allow 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, return traffic can be routed within the same network slice as that used to route the "forward" traffic, or within a different network slice but to which the equipment would also be connected.

[0019] The same problem concerns other types of connectivity verification messages (10AM request - in English "In-band Operations, Administration, and Maintenance", LSP Ping - in English "Label Switched Path", etc.).

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

[0021] 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 routing traffic to the equipment.

[0022] 3. Statement of the invention

[0023] 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.

[0024] 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.

[0025] 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.

[0026] Receiving this information allows the equipment to know that a process of verifying its reachability has been launched.

[0027] 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 verification message received 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.

[0028] 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.

[0029] 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 for a network segment enabling at least one relay entity to be identified to be requested to test the routing of data to said equipment.

[0030] In particular, if no network slice identification information is available, the control server can test all the 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.

[0031] 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.

[0032] 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.

[0033] 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.

[0034] It is noted that the equipment does not have to directly know the identity of the relay entity. For example, the equipment uses information from the control server(s) to select an appropriate control server.

[0035] 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 which 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.

[0036] 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.

[0037] 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.

[0038] 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.

[0039] In a particular embodiment, during a discovery phase or during from the authorization phase, information can be exchanged between the equipment and at least one control server.

[0040] 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.

[0041] 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 server control, • 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,

[0042] and the storage of said at least one descriptive information of said control server.

[0043] 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.

[0044] For example, such equipment is user equipment, a CPE (Customer Promises Equipment), a service instance, a router, a server, etc.

[0045] 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 comprising at least one action of “verifying the accessibility of said equipment via at least one network slice” to be executed, • generating 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 message verification.

[0046] As indicated previously, such instructions may be transmitted by the equipment, or known in advance to the control server.

[0047] 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.

[0048] 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 one type of network slice to be tested.

[0049] 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).

[0050] In particular, the equipment can respond to the verification message that it receives from the control server, in particular if the verification message is a verification request.

[0051] In this case, the method comprises: • 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.

[0052] 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.

[0053] 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 message verification (or possibly information relating to said at least one verification message).

[0054] 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).

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

[0056] In this case, the method comprises: • 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.

[0057] Conversely, 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 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.

[0058] 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).

[0059] For example, the constraint on said at least one relay entity can be deduced from the verification instructions.

[0060] 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).

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

[0062] In this case, the method comprises: • 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 • transmission to said equipment, via said secure channel between said equipment and said control server, information relating to said response.

[0063] 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 The characteristics and advantages of this control server are the same as those of the process and are not detailed further.

[0064] 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).

[0065] 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.

[0066] In particular, the equipment can respond to the verification message that it receives, in particular if the verification message is a verification request.

[0067] 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.

[0068] 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.

[0069] 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, including: • 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.

[0070] 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.

[0071] In particular, the equipment can respond to a verification message that it receives, in particular if the verification message is a verification request.

[0072] In this case, the method implemented by the relay entity comprises: • 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.

[0073] 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.

[0074] For example, such a relay entity is an edge router.

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

[0076] For example, the secure channels according to the different methods implement the QUIC secure transport protocol.

[0077] 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.

[0078] In a particular embodiment, said at least one verification message according to the different methods belongs to the group comprising: • an ICMP “Echo Request” request, a 10AM request, at least one UDP “Traceroute” packet, at least one LSP Ping packet, at least one SFC Ping packet.

[0079] 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).

[0080] 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.

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

[0082] 4. List of figures

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

[0084] 5. Description of an embodiment of the invention

[0085] 5.1 General

[0086] We consider a communication network (possibly composed of several networks or subnetworks) which 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 the 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.

[0087] For example, as illustrated in [Fig. 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 the network slices SI. #3 deployed on the subnetwork 121, SI. #2 deployed on the subnetwork 122 and SI. #2 deployed on subnetwork 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 released on May 3, 2023. .

[0088] For example, each subnetwork may be associated with a distinct domain (e.g., a communications network may be composed 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 operational functions characteristic of a 5G mobile core network). Each domain (access, collection, core, transit, etc.) can use different technologies to create network slices.

[0089] Thus, the creation of a network slice which 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.

[0090] 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.

[0091] According to another example, a network slice in a mobile network (5G for example) may be based on the establishment of network slices in the following different subnetworks / segments: radio access network (“Radio Access Network” or RAN), core network (“Core Network” or CN) and transport network (“Transport Network” or TN).

[0092] 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 making up 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 an “IETF Network Slice”.

[0093] 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).

[0094] For example, the mechanisms described in the document “A Realization of IETF Network Slices for 5G Networks Using Current IP / MPLS Technologies” cited above 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).

[0095] It is further noted that the same network slice can be used to aggregate the traffic of one or more services. Thus, as illustrated by [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 service instances 23 can be provided to the second customer UE2 via the same network slice SL #3 of the SSP network.

[0096] In addition, a network slice may involve one or more service functions (or "Service Functions" in English, according to the terminology used by the document 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). The same service function may be provided by one or more service instances.

[0097] [Fig. 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).

[0098] In a particular embodiment, service chains (Service Function Chain or 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.

[0099] These service chains may in particular 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.

[0100] 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.

[0101] We also consider a piece of equipment, connected to at least one network. A piece of equipment can be a user equipment (“User Equipment” in English), a service instance, a CPE, a server, a router, etc. The equipment can be mobile, fixed, etc.

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

[0103] 5.2 General principle

[0104] 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.

[0105] In particular, instructions or “control instructions” (in English “Probing CTL”) can be exchanged via a secure channel between the equipment and a server. dedicated control. 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.

[0106] 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.

[0107] [Fig.4] illustrates an example of a system in which the invention can be implemented.

[0108] 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).

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

[0110] 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.

[0111] At least one control server 45, also called “Probing Server” or SPS for “SALAMALEC Probing Server”, can be deployed in the network to which the UE equipment 441 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.

[0112] At least one network controller 46, also called NC for “Network Controller”, can be deployed in the network to which the equipment (SSP) is connected 42) or in a separate network. In particular, it can 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.

[0113] 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.

[0114] 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.

[0115] 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.

[0116] 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.

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

[0118] 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 4L

[0119] In one embodiment, such instructions comprise at least one of the following information: - network slice identification information to identify at least one network slice or type of network slice to be tested for routing data to the 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 the equipment. Such a relay entity corresponds for example to an injection point, that is to say to a place where verification messages can be injected into the network, as described below.

[0120] In particular, if no network slice identification information is transmitted, all network slices to which the equipment is connected (or all network slice types) can be tested.

[0121] 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.

[0122] 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.

[0123] 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.

[0124] The elements exchanged between the equipment 41 and the SPS server 45 (instructions comprising 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.

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

[0126] 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 4L. 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.

[0127] 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 4L. 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.

[0128] 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.

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

[0130] 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 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.

[0131] [Fig.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 device is connected.

[0132] 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).

[0133] 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.

[0134] 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, either issued by a relay entity.

[0135] 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.

[0136] According to this embodiment, the SPS server 45 selects (454) at least one relay entity from the 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.

[0137] In the illustrated example, the selected relay entity is for example the border router 441 or all the border routers of a network.

[0138] A network controller may also be selected (455) taking into account 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.

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

[0140] 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).

[0141] 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.

[0142] 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.

[0143] 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).

[0144] The border router 441 can then transmit (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.

[0145] 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(s) tested.

[0146] 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.

[0147] 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.

[0148] [Fig.6B] illustrates an example of messages exchanged between a piece of equipment 41, at least one control server, for example the SPS server 45, at least one controller of the network, for example the network controller 46, and at least one relay entity, for example the border router 441.

[0149] 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.

[0150] 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 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.

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

[0152] 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.

[0153] 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.

[0154] 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.

[0155] 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.

[0156] 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 border router 441 via the channel 71.

[0157] 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 packet “Traceroute”, 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 routing data from the border router 441 to the equipment 41.

[0158] 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.

[0159] 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.

[0160] 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.

[0161] 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.

[0162] [Fig.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.

[0163] As indicated previously, 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 SPS server 45 and border router 441.

[0164] 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.

[0165] The border router 441 can then perform the corresponding action(s), for example by sending one or more verification messages “Probing Messages” 72.

[0166] 5.3 Example of implementation

[0167] 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.

[0168] 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”.

[0169] 5.3.1 Equipment

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

[0171] 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 considered. For example, the ST 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). 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 (SID). 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). - a network identifier (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 of a connection routed through the network slice identified by the SID. The NID can also be useful in certain cases to facilitate the 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).

[0172] 5.3.2 Control servers

[0173] 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.

[0174] It is noted that an SPS control server can be managed by a SALAMALEC verification service provider (SPP, “SALAMALEC Probing Provider”).

[0175] A verification service provider SPP can negotiate with a network slice-based service provider SSP the activation of the SALAMALEC procedure. A dedicated API can be used for this purpose, such as the “Network Exposure Function” (NEF) API. This API makes it possible, for example, to record a list of SPS servers authorized to contact a network controller (or NC, for example an SDN controller). Such a network controller can in particular 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).

[0176] 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.

[0177] In one variant, an SPS server may interface directly with a relay entity.

[0178] 5.3.3 Discovery or authorization phase

[0179] During a first phase, the equipment proceeds to discover one or more SPS servers. An SPS server can be announced using the DNS infrastructure, a web page, an explicit configuration, etc.

[0180] Upon discovery of an SPS server, the equipment establishes a SALAMALEC channel with the SPS server, for example using a QUIC connection. As indicated, other protocols may however be considered for establishing a secure channel.

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

[0182] 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 impose the type of network slices to be tested to verify the accessibility of a device. For example, the value "0" indicates that the accessibility of the device can be tested for all types of network slices. - SLICE_ID: A SLICE_ID frame provides the identifier(s) of the network slices supported by a device or an SPS server. The SLICE_ID frame can also be used to impose the network slices to be tested 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 impose the network that hosts the network slices to be tested to verify the accessibility of a device. - 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. This PROBING_REQUEST 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, a PROBING_REPLY frame encapsulates a response ("Reply"). This response can be encapsulated by a relay entity, for example.

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

[0184] PROBING_REQUEST Frame {

[0185] Type (i),

[0186] Request_type (i),

[0187] Request,

[0188] }

[0189] 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 (I0AM), 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 ICMPvô request is: (Dst@: 2001:db8 ::2 ICMPvô 126 Echo Request id=0xl234, seq=l, hop lhnit=64).

[0190] An example of a “PROBING_REQUEST” frame format that encapsulates an ICMP type request is provided below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Destination address Port number Request type = ICMP Type Code Checksum Identifier Sequence number Reserved Metadata associated with network slices

[0191] The metadata associated with network slices, or "slice metadata", includes indications relating to the network slices. These indications can in particular be used by a node to mark data packets. In this way, the classification of the verification request to associate it with a given slice in an unambiguous manner is simplified.

[0192] 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 ICMPvô (“Internet Control Message Protocol (ICMPvô) for the Internet Protocol Version 6 (IPv6) Specification”, A. Conta et al., March 2006).

[0193] An example of a “PROBING_REQUEST” frame format that encapsulates a IOAM type query is provided below: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Destination Address Port Number Request Type = I0AM Type Code Checksum Type I0AM Length HDR I0AM Reserved Next Protocol I0AM Options / Optional Data Space Metadata Associated with Network Slices

[0194] The description of the I0AM fields is identical to that described in the documents RFC 9452 (“Network Service Header (NSH) Encapsulation for In Situ OAM (10AM) 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).

[0195] The verification request (“Request”) encapsulated in a frame "PROBING_REQUEST" can be an ICMP message (e.g., an ICMP "Echo Request" message) or any other message used to verify whether the traffic classification rules at the network ingress are properly configured to associate a given traffic with a slice.

[0196] For example, the verification request belongs to the group comprising: • an ICMP “Echo Request” request, • an IOAM query, • at least one UDP “Traceroute” packet, • at least one LSP Ping packet, • at least one SFC Ping packet.

[0197] 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.

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

[0199] The structure of a PROBING_REPLY frame is for example as follows:

[0200] PROBING_ REPLY Frame {

[0201] Type (i),

[0202] Request_type (i),

[0203] Reply,

[0204] }

[0205] with: - Type (i) and Request_type (i) as defined previously in relation to the PROBING_REQUEST frame - Reply: the response to the verification request.

[0206] 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 comprising: • 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).

[0207] 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 col mode collaborative with the SSP network (COMO), • a list of network domain identifiers with which the SPS server supports COMO collaborative mode.

[0208] 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 that to which the equipment is connected.

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

[0210] 5.3.4 Verification of reachability

[0211] 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 to the Internet network.

[0212] The equipment may optionally select the SPS server(s) to be requested to test its reachability. For example, the equipment may retain only the SPS servers internal to the network to which the equipment is connected, or only the SPS servers external to the network to which the equipment is connected, or even the SPS servers which support collaborative mode, as indicated in the COMO attribute. This selection may optionally be made by the user of the equipment, for example according to a selection confirmation request, according to a list of SPS servers to be checked using geographical indications, etc.

[0213] It is noted that the equipment can concurrently or sequentially request several SPS servers selected during the previous step.

[0214] 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 has discovered during the authorization phase if the equipment does not implement a method for selecting the SPS servers).

[0215] 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”, UDP “Traceroute” packets, LSP Ping packets, SFC Ping packets).

[0216] Alternatively, the SPS server has these instructions directly.

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

[0218] 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, and 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).

[0219] 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.

[0220] 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.

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

[0222] 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 sent 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.

[0223] 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.

[0224] The SPS server may transmit the PROBING_REQUEST frame(s) to at least one relay entity selected from the instructions, either directly or by via a network controller. For example, the SPS server may transmit 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).

[0225] 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.

[0226] One or more relay entities, for example a router at the edge of the network (Border Router or BR), can be requested by the network controller to execute the verification requests according to the instructions of an SPS server.

[0227] 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 on a secure channel established between the network controller and the relay entity.

[0228] A relay entity receiving a PROBING_REQUEST frame can decapsulate the PROBING_REQUEST frame to retrieve the verification request "Request". The verification request can thus be sent by the relay entity (a router at the edge of the network for example). Such a relay entity can in particular use its own source address to send the verification request(s).

[0229] The response(s) received by the relay entity may be forwarded to the network controller in a PROBING_REPLY frame. The network controller may forward the PROBING_REPLY frame to the SPS server, which may in turn forward it to the equipment.

[0230] 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 sent 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.

[0231] 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. information it has generated. A deadline may optionally be communicated to control the time beyond which the equipment ends the verification step.

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

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

[0234] 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 has received if applicable. For example, the SPS server receives a response following the verification request that it has issued. Such a response can be an 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 equipment. 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 equipment.

[0235] 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.

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

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

[0238] According to the example illustrated by [Fig.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. [Fig.8] illustrates an example where reachability via a network slice is confirmed.

[0239] Thus, the equipment 81 sends instructions to the SPS server 85. The latter generates a verification request and sends to the equipment 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 equipment 81 receives the ICMP “Echo Request” request via the border router BR 841. The equipment 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.

[0240] According to the example illustrated by [Fig.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. [Fig.9] illustrates an example where reachability via a network slice is not confirmed.

[0241] Thus, the equipment 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 equipment 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 equipment 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 equipment 91. The failure of reachability is for example linked to the inadequacy of the traffic classification rules.

[0242] According to the example illustrated by [Fig. 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. [Fig. 10] illustrates an example where the reachability via a network slice is confirmed from one or more edge routers (e.g., a first edge router 1041 and a second edge router 1042).

[0243] Thus, the equipment 101 sends instructions to the SPS server 105, via the first edge router 1041. The SPS server 105 generates a verification request and sends to the equipment 101 information relating to the verification request (e.g., a PROBING_REQUEST frame encapsulating the verification request). The SPS server 105 also sends the verification request or the PROBING_REQUEST frame to the network controller 106. The latter sends it to the second edge router 1042.

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

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

[0246] 5.4 Variants

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

[0248] 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 so that it does not filter the 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 the RFC8040 (“RESTCONF Protocol”) documents,

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

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

[0251] 5.5 Simplified structure of corresponding entities

[0252] Finally, in relation to [Fig.l 1], 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.

[0253] As illustrated by [Fig. 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.

[0254] At 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.

[0255] 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.

[0256] 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 to verify 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.

[0257] 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 slice network, described above, 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, • transmit to at least one selected relay entity said at least one verification message.

[0258] 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 piece of equipment for the routing of data to said piece of equipment 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

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 for 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 making it possible to identify at least one network slice or a type of network slice to be tested for the routing of data to said equipment, • network segment identification information 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 for verifying the accessibility of said equipment via at least one network slice to be executed, • generating (452) at least one verification message from said instructions, • transmitting (453) to said equipment, via a secure channel (50) between said equipment and said control server, 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 controlling the accessibility of equipment for routing data to said equipment, via at least one network slice, implemented by a network controller, comprising: • the reception (461) of 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, • the transmission (462) to at least one selected relay entity of said at least one verification message.

10. Method for performing 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: • the reception (4411) of 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 performed by said relay entity, • the transmission (4412), to said equipment, of said at least one verification message.

11. Method according to any one of claims 1 to 10, characterized in that said at least one verification message belongs to the group comprising: • an ICMP “Echo Request” request, • a 10AM request, • at least one UDP “Traceroute” packet, • at least one LSP Ping packet, • at least one SFC Ping packet.

12. Method according to any one of claims 1 to 11, characterized in that said secure channel implements a QUIC secure transport protocol.

13. 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.

14. Control server capable of managing the accessibility of equipment for routing data to said equipment, via at least one network slice, comprising at least one processor configured to: • obtain instructions comprising at least one action for 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.

15. Network controller capable of controlling the accessibility of equipment for routing 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, 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, • transmit to at least one selected relay entity said at least one verification message; minus a verification message.

16. 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 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 carried out by said relay entity, • transmit, to said equipment, said at least one verification message.

Images