WO2023281200A1 - Gestion d'au moins une entite d'orchestration dans un reseau logiciel - Google Patents

Gestion d'au moins une entite d'orchestration dans un reseau logiciel Download PDF

Info

Publication number
WO2023281200A1
WO2023281200A1 PCT/FR2022/051332 FR2022051332W WO2023281200A1 WO 2023281200 A1 WO2023281200 A1 WO 2023281200A1 FR 2022051332 W FR2022051332 W FR 2022051332W WO 2023281200 A1 WO2023281200 A1 WO 2023281200A1
Authority
WO
WIPO (PCT)
Prior art keywords
network
state
orchestration
metrics
time window
Prior art date
Application number
PCT/FR2022/051332
Other languages
English (en)
Inventor
Jose Manuel SANCHEZ VILCHEZ
Alessio DIAMANTI
Stefano Secci
Original Assignee
Orange
Conservatoire National des Arts et Métiers
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange, Conservatoire National des Arts et Métiers filed Critical Orange
Priority to EP22750865.2A priority Critical patent/EP4367857A1/fr
Publication of WO2023281200A1 publication Critical patent/WO2023281200A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
    • H04L41/0816—Configuration setting characterised by the conditions triggering a change of settings the condition being an adaptation, e.g. in response to network events
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0806—Configuration setting for initial configuration or provisioning, e.g. plug-and-play
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0895—Configuration of virtualised networks or elements, e.g. virtualised network function or OpenFlow elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/40—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using virtualisation of network functions or resources, e.g. SDN or NFV entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS
    • H04L41/5009—Determining service level performance parameters or violations of service level contracts, e.g. violations of agreed response time or mean time between failures [MTBF]

Definitions

  • the invention relates to the general field of telecommunications. It is more precisely situated in the context of networks known under the name of “software networks”, based on SDN (in English “Software Defined Networking”) and NFV (in English “Network Functions Virtualization”) technologies.
  • the invention finds a particular but non-limiting application in fifth generation (5G) networks which rely on these SDN and NFV technologies to offer specialist/vertical service providers (telemedicine, security, autonomous vehicle, virtual private network or VPN (for Virtual Private Network in English), videoconferencing, etc.), through “network slices” (in English network slice), services in which the level of performance (in terms of latency, throughput , reliability, etc.) is certified by an interconnection service contract (SLA, in English Service Level Agreement) established between the operator and the service provider.
  • SLA in English Service Level Agreement
  • FIG. 1 schematically represents the architecture of a prior art software network, only the main components useful for understanding the invention, all known to those skilled in the art, being represented.
  • the upper FOP layer groups together the operator's support and business functions.
  • VNF virtualized Network Functions
  • This service is implemented using two operational layers, namely an LM layer of hardware and software resources and an LV layer of virtualized resources.
  • These operational layers LM, LV can be deployed on an NFVI infrastructure for virtualization of network functions, typically located in one or more data centers (or data centers in English) interconnected with one another.
  • This NFVI infrastructure offers, via a VL virtualization layer, access to all the hardware and software resources of the LM layer which constitute the environment in which the VNFs are deployed.
  • material and software resources have been represented in layer LM, resources C of CPU type, resources M of memory type, resources D of disk type and resources N of network type.
  • the corresponding virtualized resources are referenced in the same way in the virtual resources LV layer.
  • management and orchestration functions including:
  • NFVO NFV orchestrator
  • VNFM manager
  • VIM manager
  • the VIM manager is specifically responsible for placing virtual machines and managing their lifecycles.
  • the SDN separates the control plane of the network from the data routing plane.
  • the control plane is implemented in SDN controllers.
  • two SDN controllers are represented, more precisely a T-SDN controller (in English “Tenant SDN controller”) and an I-SDN controller (in English “Infrastructure SDN controller”), following the ETSI NFV standard defined in document ETSI GS NFV-EVE 005, "Network Functions Virtualization (NFV); Ecosystem; Report on SDN Reading in NFV Architectural Framework," v. 1.1.1, Dec. 2015.
  • the T-SDN and I-SDN controllers are in particular responsible for choosing the path for routing the packets, respectively at the level of the virtual resources layer and at the level of the hardware and software resources layer.
  • orchestration entities EO denotes the management and orchestration functions MANO NFVO, VNFM, VIM and the SDN controllers T-SDN, I-SDN. These orchestration entities EO act on a group of resources in an operational layer LM, LV. For example :
  • the VIM manager can change the amount of CPU allocated to a virtual machine by acting on the CPU type C resources of the LV layer of virtual resources;
  • the T-SDN controller acts on the network type N resources of the LV layer of the virtual resources;
  • the I-SDN controller acts on the network type N resources of the LM layer of hardware and software resources.
  • Software networks make it possible to meet the levels required in particular by 5G networks because network delivery and management are becoming highly dynamic (with services made up of virtualized resources, deployed on the fly). Nevertheless, software networks introduce new potential weaknesses, in particular due to the distribution of decision-making. For example, SDN controllers can make control decisions, and other orchestration entities, such as the VNFM manager or the NFVO orchestrator can decide to reconfigure software network functions.
  • Managing SDN/NFV networks can reach a level of functional complexity that is difficult to master. This level of complexity is mainly due to two factors:
  • the invention aims at a solution for improving the control of software networks.
  • the invention relates to a method for managing at least one orchestration entity in a software network, this method comprising:
  • a step of obtaining at least one state of the network in said time window said state of the network comprising a state of a service implemented in the network and a state of at least one operational layer of the network for the implementation of said service;
  • the invention relates to a device for managing at least one orchestration entity in a software network, this device comprising:
  • a module for obtaining at least one state of the network in said time window said state of the network comprising a state of a service implemented in the network and a state of at least one operational layer of the network for the implementation of said service;
  • - a module for obtaining, from said state of the network and from a reference state of said network, a reputation value representative of an improvement or degradation of a state of the network;
  • the invention relates to an orchestration method implemented by an orchestration entity in a software network, the method comprising:
  • an orchestration entity comprising:
  • a module for selecting an orchestration action configured to take into account said reputation value to select an orchestration action to be performed in said network.
  • the invention proposes a method and a management device configured to determine whether an orchestration action performed by an orchestration entity in a software network has the effect of improving or degrading the network status.
  • This management device calculates a so-called reputation value representative of this improvement or this degradation and communicates it to the orchestration entity.
  • the orchestration entity uses this reputation value to select future orchestration actions it performs in the software network. These reputation values thus serve as feedback to the orchestration entities on the impact of their orchestration actions on the state of the network and allow them to adapt these orchestration actions accordingly.
  • the NFVO orchestrator coordinates the allocation of hardware resources, for example by reserving or releasing hardware physical resources from the data center (datacenter).
  • the NFVO orchestrator can for example take an orchestration action to choose not to use or release a failed or overloaded VNF;
  • the VNFM manager creates, maintains and frees the instances of the VNF virtual functions: creation, scaling, maintenance and freeing of the instances of the VNFs.
  • the VNFM manager can for example take an orchestration action to add an instance of a VNF;
  • the VIM manager manages the allocation, addition, release and recovery of NFVI infrastructure resources (storage, CPU, network cards, memories, ...) as well as their optimization.
  • the VIM manager can for example take an orchestration action to allocate computing resources to virtual machines;
  • an SDN controller can for example take an orchestration action to configure a new network path for routing packets when it detects that a path in use is down or congested. It is usual in this context to define by "resilience" the ability of an orchestration entity or a system to respond to and compensate for deviations in the state of the network by applying orchestration actions to return from a state of the network degraded by a disturbance to a known and stable reference state.
  • the invention proposes a solution for improving the resilience of orchestration entities by setting up a reputation mechanism which evaluates the impact of the orchestration actions executed by these entities in terms of deviation on network resilience.
  • the management device is typically implemented in a central function of the software network to manage all the orchestration entities, such as in particular the SDN controllers and the MANO management and orchestration functions (NFVO, VNFM, VIM) mentioned previously.
  • orchestration entities such as in particular the SDN controllers and the MANO management and orchestration functions (NFVO, VNFM, VIM) mentioned previously.
  • the state of the network can be defined by a state of the service and by a state of at least one operational layer allowing the implementation of this service.
  • the state of the service can be obtained from metrics describing the service at different instants of the time window. For example, you can use:
  • state of the operational layer or layers it is possible for example to use (i) a state of a layer of hardware and software resources and/or (ii) a state of a layer of virtual resources of said network .
  • the state of an operational layer in a time window is for example obtained from metrics describing this layer at different instants of this time window.
  • operational metrics used to describe a layer of hardware and software resources at a given time may include:
  • operational metrics used to describe a layer of virtual resources at a given time may include:
  • the state of the network is calculated by a learning-based system taking as input the service metrics and at least a subset of the metrics of at least one operational layer.
  • the operational layer (layer of hardware and software resources or layer of virtual resources) is described from the metrics of a single group of resources.
  • CPU type metrics may for example be CPU type metrics, memory type metrics, disk type metrics or network resource type metrics.
  • this embodiment is advantageous because an orchestration action generally targets a single group of resources, for example, adding memory, performing vertical or horizontal CPU scaling.
  • the reputation value is increased or decreased depending on whether the state of the network approaches or moves away from the reference state with respect to a state in which the network was in a time window prior to said time window.
  • these states are represented in a two-dimensional space in which a first dimension represents the state of the service and a second dimension represents the state of the operational layer which makes this service in the network.
  • Such a space known as the “resilience space” has been defined by Sterbenz et. al in the document “Evaluation of network resilience, survivability, and disruption tolerance: analysis, topology generation, simulation, and experimentation 2013-02. ".
  • the invention also relates to a system comprising a management device and at least one orchestration entity as mentioned above.
  • the management and orchestration methods can be implemented by a computer program.
  • the invention also relates to a computer program on a recording medium, this program being capable of being implemented in a computer, this program comprises instructions allowing the implementation of a management method or the implementation of an orchestration method as described above.
  • This program may use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in partially compiled form, or in any other desirable form.
  • the invention also relates to an information medium or a recording medium readable by a computer, and comprising instructions of a computer program as mentioned above.
  • the information or recording medium can be any entity or device capable of storing the programs.
  • the media may comprise a storage medium, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or even a magnetic recording medium, for example a diskette (floppy disk) or a disc hard, or flash memory.
  • the information or recording medium may be a transmissible medium such as an electrical or optical signal, which may be routed via an electrical or optical cable, by radio link, by wireless optical link or by other ways.
  • the program according to the invention can in particular be downloaded from an Internet-type network.
  • the information or recording medium may be an integrated circuit in which a program is incorporated, the circuit being adapted to execute or to be used in the execution of one of the methods as described previously.
  • the management method, the orchestration method, the management device, the orchestration entity and the system according to the invention may have in combination all or part of the aforementioned characteristics.
  • FIG. 1 already described represents a software network conforming to the state of the art
  • FIG. 2 represents a system in accordance with a particular embodiment of the invention
  • FIG. 3 represents successive states of a network in a resilience space
  • Figure 4 illustrates the effect of an orchestration action
  • Figure 5 illustrates distances between states in a resilience space
  • Figure 6 illustrates the calculation of reputations in different situations
  • FIG. 7 represents the main steps implemented by the modules, devices and entities of the system of FIG. 2 in a particular embodiment
  • FIG. 8 represents the hardware architecture of a management device according to a particular embodiment of the invention.
  • FIG. 9 represents the functional architecture of a management device according to a particular embodiment of the invention.
  • FIG. 10 represents the hardware architecture of an orchestration entity in accordance with a particular embodiment of the invention.
  • FIG. 11 represents the functional architecture of an orchestration entity in accordance with a particular embodiment of the invention.
  • FIG. 2 represents a system S in accordance with an embodiment of the invention. This system is described in the context of the analysis of a virtualized network RV in which a service SV is implemented, this service SV relying on virtualized network functions VNF.
  • the state S S v ' of this service SV can be defined from a set (or joint) smsv ' of nSV service metrics at this instant ti , nSV designating an integer greater than or equal to 1.
  • smsv ' [siri ! 1 ',. ⁇ , sirinsv 1 ']
  • service metrics include for example:
  • a predetermined function fsv is used to estimate a state S S v 'of the service SV at time ti from metrics sm s v 11 .
  • the states Sa 1 of the service SV calculated at different instants ti make it possible to define a state S S v k of the service SV in a time window T k .
  • This state S S v k can here be qualified as stable.
  • S S v k is the mean of the states Ssv 11 of the service SV calculated at different instants ti of the time window T k .
  • statistical functions other than the average for example regression functions, can be used to calculate a state S S v k of the service for the time window T k from the instantaneous service states Sa 1 .
  • the implementation of the SV service involves two operational layers, namely:
  • an operational layer LM of hardware and software resources (servers, etc.).
  • operational metrics om LM i used to describe the LM layer of hardware and software resources at time ti may include:
  • operational metrics oh n ' used to describe the LV layer of virtual resources at time ti may include:
  • a predetermined function f LM is used to estimate a state S LM 11 of the operational layer LM of the hardware and software resources at the instant ti from the metrics om ⁇ .
  • the states S LM 11 of the operational layer LM of the hardware and software resources calculated at different instants ti make it possible to define a state (qualified as stable) S LM k of this layer in a time window T k .
  • S LM k is the mean of the states S LM 11 of the LM layer calculated at different instants ti of the time window T k .
  • statistical functions other than the average for example regression functions, can be used to calculate a state S LM k of the LM layer for the time window T k from the instantaneous states S LM 11 ⁇
  • a predetermined function f L v is used to estimate a state S LV 1 of the operational layer LV of the virtual resources at time ti from the OITI metrics LV 1 .
  • the states S LV 11 of the operational layer LV of the virtual resources calculated at different instants ti make it possible to define a state (qualified as stable) S L v k of this layer in a time window T k .
  • S L v k is the mean of the states S LV 11 of the LV layer calculated at different instants ti of the time window T k .
  • statistical functions other than the average for example regression functions, can be used to calculate a state S L v k of the LV layer for the time window T k from the instantaneous states S L v '
  • an operational layer LM or LV will be designated by L and by G the metrics of a particular type of resource.
  • G can take 4 values C, M, D and N to designate relative metrics:
  • CPU metrics are for example:
  • the invention proposes to define eight states of the software network S k(G,L) in the time window T k , with:
  • - L LM or LV.
  • the notation S k(N ' LV) designates a state of the software network defined by:
  • the states S k , S k+1 , S k+2 of the software network ((G,L) omitted for simplicity) in successive time windows T k , T k+1 , T k+2 can be represented in a two-dimensional space in which:
  • the dimension DP (ordinate axis) represents the state Ssv k of the service SV.
  • the dimension DN (axis of abscissas) represents an operational state S L k of a material operational layer LM or virtual LV which renders this service in the network.
  • the system S comprises a module MOM for obtaining the metrics of the virtualized network.
  • this MOM module is configured to collect, at different times ti:
  • the system S comprises a module MOE for obtaining states S k of the software network in different time windows T k from the service metrics smsv ' and the operational metrics om ⁇ 1 and omi 11 collected by the MOM module at different instants ti in these time windows T k .
  • the MOE module for obtaining states uses predetermined functions f s , Vi, fi_v to calculate the states S s k of the service SV, the states S L k of the operational layer of the virtual resources LV and the states S LM k of the operational layer of the hardware resources LM in the time window T k from the different metrics.
  • These functions f S v, Vi, fi_v are for example classification functions capable of carrying out a matching (in English mapping) of the metrics towards a state.
  • the function f S v can be a function capable of matching the metrics sm ⁇ 1 with a service state Ssv 1 ⁇
  • These functions can be implemented in the form of neural networks.
  • the MOE module for obtaining states uses a learning-based method (in English Machine Learning) ML which takes as input the metrics oh M 11 and om ⁇ 1 of the operational layers LM and LV and the service metrics smsv 11 to compress these metrics and calculate the states S k of the network at each time window T k .
  • ML English Machine Learning
  • this method can use an auto-encoder and use a reconstruction error to compress the metrics omi 1 ', om ⁇ 1 and smsv 11 to a single indicator S k .
  • this method can combine a dimensionality reduction technique, for example the Principal Component Analysis (PCA) method and a clustering technique to project the metrics onto a two-dimensional space, recognize clustering ( in English clusters) metrics and define the states from these groupings.
  • PCA Principal Component Analysis
  • the state obtaining module MOE can calculate the successive states S k(G,L) (and the transitions) for each operational layer L (LM or LV) and for each group G of metrics C, D, M and N (CPU, disk, memory and network).
  • the state obtaining module MOE saves the states S k or S k (G, L) in a buffer memory MT.
  • FIG. 4 generally illustrates an objective targeted by the EO orchestration entities (NFVO, VNFM, VIM, T-SDN, I-SDN).
  • a role of the orchestration entities EO is to set up one or more orchestration actions to compensate for such a state deviation D, so that the network returns or tends to return from its degraded state S k to its reference state S R as illustrated by the arrow in dotted lines in Figure 4.
  • an orchestration entity such as the VIM, which manages virtual machines, may observe that the CPU level is insufficient (degraded state) and apply a vertical or horizontal scalability orchestration action.
  • each orchestration entity EO saves in the buffer memory MT an indication IA k if it has implemented one or more orchestration actions A k during the time window T k .
  • ViM an indication that one or more actions have been performed by the VIM manager during the time window T k .
  • the system S comprises a management device TRM configured to obtain from the buffer memory MT:
  • the management module TRM when the management module TRM receives the information according to which the software network is, in a time window T k , in a degraded state S k and it becomes aware that an orchestration entity EO has performed an action during this time window T k , the module TRM sends to this orchestration entity EO a reputation value r EO k inversely proportional to the distance between the representation of the state S R reference the representation of the degraded state S k in the resilience space of figure 4.
  • the TRM module uses a reputation model such that the reputation value r E o k is difficult to win but easy to lose, to discourage orchestration actions A k of the orchestration entities EO which move the state of the system away from the reference state S R and which aggravate the breakdowns by having a negative impact on the network.
  • the reputation r EO k of an orchestration entity EO which distances the current state from the reference state S R , must drop sharply, decrease considerably or become relatively low.
  • said reputation value r EO k is increased or decreased depending on whether said state S k of the network approaches or moves away from said reference state S R with respect to a state S kl of the network in a time window T kl prior to said time window T k .
  • the module TRM considers that a transition which occurs in a time window T k is spontaneous if this module TRM receives no indication IA k of an orchestration action A k for this time window;
  • non-spontaneous transitions in which the network switches from a state S kl to a new state S k due to an orchestration action A k performed by an orchestration entity EO, this action being able to have a positive impact (S k approaches the reference state S R compared to S kl ) or negative (S k moves away from the reference state S R compared to S kl ) on the network.
  • the modules D AkN and D AkP are positive.
  • the module TRM sends to the orchestration entity EO having performed the action A k a negative reputation value r EO k proportional to D AkP and inversely proportional to D ? , D ? also designating the distance between S R and S kl .
  • the component D AkN is negative and the component D AkP is positive.
  • the module TRM sends to the orchestration entity EO having performed the action A k a negative reputation value r EO k proportional to D AkP /D ? .
  • the TRM module sends to the orchestration entity EO having performed the action A k a negative reputation value r EO k proportional to D AkN /D ? .
  • the module TRM sends to the orchestration entity EO having performed the action A k a reputation value r EO k positive and proportional to D Ak and inversely proportional to D ? .
  • the orchestration entities EO receive the reputation values r EO k from the module TRM.
  • r ViM k the reputation value that the TRM module sends to the VIM manager.
  • each orchestration entity EO has a reputation value r E0 of zero. Then, as an orchestration entity EO performs orchestration actions A k , this entity EO receives reputation values r EO k from the TRM module which allow this orchestration entity EO to understand whether the orchestration actions A k carried out with the aim of correcting a degraded state of the network are effectively effective in bringing the network back to or towards its reference state S R .
  • these reputation values r EO k serve as feedback to the orchestration entities on the impact of their orchestration actions.
  • the orchestration entities EO use the reputation values r EO k to optimize and/or correct their future orchestration actions in order to better react to future degradations.
  • each orchestration entity EO includes an RL agent configured to implement a Reinforcement Learning (RL) method.
  • This agent RL receives as input the reputation values r EO k and selects as output the appropriate orchestration actions to react to a given degradation.
  • VNFM manager to improve the support of the life cycle of the VNFs
  • VNF network function
  • FIG. 7 represents the main steps implemented by the modules, devices and entities of the system of FIG. 2 in a particular embodiment.
  • the steps implemented by the management device TRM constitute an example of a management method in accordance with the invention.
  • the steps implemented by the orchestration entity EO constitute an example of an orchestration method in accordance with the invention.
  • the MOM module for obtaining obtains at different times ti:
  • the module MOM communicates these metrics to the status obtaining module MOE during a step E20.
  • the state obtaining module MOE calculates the states S k of the network for different time windows T k . It uses for example a method based on learning which takes as input the metrics oh M 11 and om ⁇ 1 of the operational layers LM and LV and the service metrics smsv 11 .
  • the module MOE communicates the states S k of the network to the management device TRM during a step E40.
  • an orchestration entity EO decides on the orchestration actions to be performed in the software network. It performs action A k during a step E60. During a step E70, it sends to the management device TRM an indication IA E o k according to which it has performed at least one orchestration action during the time window T k .
  • the management device TRM calculates a reputation value r E o k for the time window T k and the orchestration entity EO.
  • This reputation value r EO k represents the fact that the state S k of the network has been improved or degraded by the action A k performed by the orchestration entity EO.
  • the management device TRM sends the reputation value r EO k to the orchestration entity EO during a step E90.
  • FIG. 8 represents the hardware architecture of a management device TRM in accordance with a particular embodiment of the invention.
  • this device has the hardware architecture of a computer. It comprises a processor 10, communication means 11 on a network, a random access memory of the RAM type 12, a rewritable non-volatile memory 13 and a read only memory 14.
  • the read only memory constitutes an information medium for storing a program of PG-TRM computer according to the invention.
  • the processor 10 executes this computer program, it implements the management method described with reference to FIG. 7.
  • FIG. 9 represents the functional architecture of a management device TRM in accordance with a particular embodiment of the invention.
  • This device can be implemented in hardware as shown in Figure 8. It comprises:
  • a module M40 for obtaining at least one state S k of the network in said time window T k , said state S k of the network comprising a state S S v k of a service implemented in the network and a state S L K of at least one operational layer of the network for the implementation of this service SV;
  • a module M80 for obtaining, from said state of the network S k and from a reference state S R of said network, a reputation value r E o k representative of an improvement or a deterioration of the network status;
  • FIG. 10 represents the hardware architecture of an orchestration entity EO conforming to a particular embodiment of the invention.
  • this EO entity has the hardware architecture of a computer. It comprises a processor 20, communication means 21 on a network, a random access memory of the RAM type 22, a rewritable non-volatile memory 23 and a read only memory 24.
  • the read only memory constitutes an information medium for storing a program of PG-EO computer according to the invention.
  • the processor 20 executes this computer program, it implements the orchestration method described with reference to FIG. 7.
  • FIG. 11 represents the functional architecture of an orchestration entity EO in accordance with a particular embodiment of the invention.
  • This entity can be implemented in hardware as shown in Figure 10. It includes:
  • a module M700 for sending, to a management device TRM, an indication IA k according to which said orchestration entity EO has performed at least one orchestration action A k in said network during a window of time Tk ;
  • an M500 module for selecting an orchestration action this modulated being configured to take into account said reputation value r EO k to select an orchestration action to be performed in the network.

Landscapes

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

Abstract

Ce procédé gère au moins une entité d'orchestration (EO) dans un réseau logiciel. Il comporte : une étape (E70) d'obtention d'une indication (IAk) selon laquelle ladite entité d'orchestration (EO) a effectué au moins une action d'orchestration (Ak) dans ledit réseau au cours d'une fenêtre de temps (Tk); une étape (E40) d'obtention d'au moins un état (Sk) du réseau dans ladite fenêtre de temps (Tk), ledit état (Sk) du réseau comportant un état d'un service mis en œuvre dans le réseau et un état d'au moins une couche opérationnelle du réseau pour la mise en œuvre dudit service; une étape (E80) d'obtention, à partir dudit état du réseau (Sk) et d'un état de référence dudit réseau, d'une valeur de réputation (rEO k) représentative d'une amélioration ou d'une dégradation d'un état du réseau (Sk); et - une étape (E90) d'envoi de ladite valeur de réputation (rEO k) à ladite entité d'orchestration (EO).

Description

GESTION D'AU MOINS UNE ENTITE D'ORCHESTRATION DANS UN RESEAU LOGICIEL
Description
Titre de l'invention : Procédé de gestion d'au moins une entité d'orchestration dans un réseau logiciel
Technique antérieure
L'invention se rapporte au domaine général des télécommunications. Elle se situe plus précisément dans le contexte des réseaux connus sous le nom de « réseaux logiciels », basés sur les technologies SDN (en anglais « Software Defined Networking ») et NFV (en anglais « Network Functions Virtualization).
L'invention trouve une application particulière mais non limitative dans les réseaux de cinquième génération (5G) qui s'appuient sur ces technologies SDN et NFV pour offrir à des fournisseurs de service spécialisés /verticaux (télémédecine, sécurité, véhicule autonome, réseau virtuel privé ou VPN (pour Virtual Private Network en anglais), visio-conférence, etc.), par le biais de « tranches de réseau » (en anglais network slice), des services dans lesquels le niveau de performance (en termes de latence, débit, fiabilité, etc.) est certifié par un contrat de service d'interconnexion (SLA, en anglais Service Level Agreement) établi entre l'opérateur et le fournisseur de service.
La figure 1 représente schématiquement l'architecture d'un réseau logiciel de l'état de la technique, seuls les principaux composants utiles à la compréhension de l'invention, tous connus de l'homme du métier, étant représentés.
Sur la figure 1, la couche supérieure FOP regroupe les fonctions support et métiers de l'opérateur. On considère un service qui s'appuie sur des fonctions réseau virtualisées VNF (en anglais Virtualized Network Functions). Ce service est mis en oeuvre grâce à deux couches opérationnelles, à savoir une couche LM de ressources matérielles et logicielles et une couche LV de ressources virtualisées. Ces couches opérationnelles LM, LV peuvent être déployées sur une infrastructure NFVI de virtualisation des fonctions réseau, typiquement localisée dans un ou plusieurs centres de données (ou datacenters en anglais) interconnectés entre eux. Cette infrastructure NFVI offre, via une couche de virtualisation VL, accès à l'ensemble des ressources matérielles et logicielles de la couche LM qui constituent l'environnement dans lequel les VNF sont déployées.
Sur cette figure 1, on a représenté, dans la couche LM des ressources matérielles et logicielles, des ressources C de type CPU, des ressources M de type mémoire, des ressources D de type disque et des ressources N de type réseau. Les ressources virtualisées correspondantes sont référencées de la même façon dans la couche LV des ressources virtuelles.
Le déploiement, l'exécution et l'exploitation des VNF dans l'infrastructure NFVI sont pilotés par des fonctions de gestion et d'orchestration (MANO) comprenant :
- un orchestrateur NFV (NFVO) en charge du cycle de vie des services réseau ; - un gestionnaire (VNFM) en charge du cycle de vie des VNFs ; et
- un gestionnaire (VIM) en charge de la gestion des ressources de l'infrastructure NFVI. Le gestionnaire VIM est en particulier responsable du placement des machines virtuelles et de la gestion de leurs cycles de vie.
Par ailleurs, et de façon connue, le SDN dissocie le plan de contrôle (control plane en anglais) du réseau du plan d'acheminement des données (data plane en anglais). Le plan de contrôle est mis en oeuvre dans des contrôleurs SDN. Sur cette figure 1, on a représenté deux contrôleurs SDN, plus précisément un contrôleur T-SDN (en anglais « Tenant SDN controller ») et un contrôleur I-SDN (en anglais « Infrastructure SDN controller »), en suivant la norme ETSI NFV définie dans le document ETSI GS NFV-EVE 005, "Network Functions Virtualisation (NFV); Ecosystem; Report on SDN Lisage in NFV Architectural Framework," v. 1.1.1, Dec. 2015.
Les contrôleurs T-SDN et I-SDN sont en particulier responsables du choix du parcours d'acheminement des paquets, respectivement au niveau de la couche de ressources virtuelles et au niveau de la couche des ressources matérielles et logicielles.
Dans ce document, on désigne par « entités d'orchestration » EO, les fonctions MANO de gestion et d'orchestration NFVO, VNFM, VIM et les contrôleurs SDN T-SDN, I-SDN. Ces entités d'orchestration EO agissent sur un groupe de ressources dans une couche opérationnelle LM, LV. Par exemple :
- le gestionnaire VIM peut changer la quantité de CPU alloué à une machine virtuelle en agissant sur les ressources C de type CPU de la couche LV des ressources virtuelles ;
- le contrôleur T-SDN agit sur les ressources N de type réseau de la couche LV des ressources virtuelles ;
- le contrôleur I-SDN agit sur les ressources N de type réseau de la couche LM des ressources matérielles et logicielles.
Les réseaux logiciels permettent de répondre aux niveaux requis notamment par les réseaux 5G car la livraison et la gestion de réseau deviennent fortement dynamiques (avec des services composés de ressources virtualisées, déployées à la volée). Néanmoins, les réseaux logiciels introduisent de nouvelles faiblesses potentielles, en raison notamment de la distribution des prises de décisions. Par exemple, les contrôleurs SDN peuvent prendre des décisions de contrôle, et d'autres entités d'orchestration, comme le gestionnaire VNFM ou l'orchestrateur NFVO peuvent décider de reconfigurer des fonctions du réseau logiciel.
La gestion des réseaux SDN/NFV peut atteindre un niveau de complexité fonctionnelle difficile à maîtriser. Ce niveau de complexité est dû principalement à deux facteurs :
- la séparation entre le logiciel et le matériel à travers l'hyperviseur constituant la plateforme logicielle de virtualisation du système NFV ; et
- la séparation entre le plan de transfert ou d'acheminement des données (data plane) et le plan de contrôle (control plane) aussi bien dans les architectures SDN (pour l'accès au contrôleur) que pour les architectures NFV (pour l'accès à l'orchestrateur). Ces deux facteurs conduisent à une architecture SDN/NFV multicouche, dans laquelle différentes entités de gestion (comme les orchestrateurs) et différentes entités de contrôle (comme les contrôleurs SDN) peuvent prendre des décisions critiques difficiles à anticiper ou contrôler et susceptibles d'impacter la qualité de service QoS (en anglais Quality of Service).
L'invention vise une solution pour améliorer le contrôle des réseaux logiciels.
Exposé de l'invention
Plus précisément, et selon un premier aspect, l'invention concerne un procédé de gestion d'au moins une entité d'orchestration dans un réseau logiciel, ce procédé comportant :
- une étape d'obtention d'une indication selon laquelle ladite entité d'orchestration a effectué au moins une action d'orchestration dans ledit réseau au cours d'une fenêtre de temps ;
- une étape d'obtention d'au moins un état du réseau dans ladite fenêtre de temps, ledit état du réseau comportant un état d'un service mis en oeuvre dans le réseau et un état d'au moins une couche opérationnelle du réseau pour la mise en oeuvre dudit service ;
- une étape d'obtention, à partir dudit état du réseau et d'un état de référence du réseau, d'une valeur de réputation représentative d'une amélioration ou d'une dégradation d'un état du réseau ; et
- une étape d'envoi de ladite valeur de réputation à ladite entité d'orchestration.
Dans ce document ; on désigne par « couches opérationnelles » :
- la couche des ressources matérielles et logicielles utilisées pour la mise en oeuvre du service ; et
- la couche des ressources virtualisées utilisées pour la mise en oeuvre du service.
Corrélativement l'invention concerne un dispositif de gestion d'au moins une entité d'orchestration dans un réseau logiciel, ce dispositif comportant :
- un module d'obtention d'une indication selon laquelle ladite entité d'orchestration a effectué au moins une action d'orchestration dans ledit réseau au cours d'une fenêtre de temps ;
- un module d'obtention d'au moins un état du réseau dans ladite fenêtre de temps, ledit état du réseau comportant un état d'un service mis en oeuvre dans le réseau et un état d'au moins une couche opérationnelle du réseau pour la mise en oeuvre dudit service ;
- un module d'obtention, à partir dudit état du réseau et d'un état de référence dudit réseau, d'une valeur de réputation représentative d'une amélioration ou d'une dégradation d'un état du réseau ; et
- un module d'envoi de ladite valeur de réputation à ladite entité d'orchestration.
Selon un deuxième aspect, l'invention concerne un procédé d'orchestration mis en oeuvre par une entité d'orchestration dans un réseau logiciel, le procédé comportant :
- une étape d'envoi, à un dispositif de gestion, d'une indication selon laquelle ladite entité d'orchestration a effectué au moins une action d'orchestration dans ledit réseau au cours d'une fenêtre de temps ;
- une étape de réception d'une valeur de réputation obtenue par ledit dispositif de gestion en mettant en œuvre un procédé de tel que mentionné ci-dessus ; et
- une étape de prise en compte de ladite valeur de réputation pour sélectionner une action d'orchestration à effectuer dans ledit réseau.
Corrélativement, l'invention concerne une entité d'orchestration comportant :
- un module d'envoi, à un dispositif de gestion tel que mentionné ci-dessus d'une indication selon laquelle ladite entité d'orchestration a effectué au moins une action d'orchestration dans ledit réseau au cours d'une fenêtre de temps ;
- un module de réception d'une valeur de réputation en provenance dudit dispositif de gestion ; et
- un module de sélection d'une action d'orchestration configuré pour prendre en compte ladite valeur de réputation pour sélectionner une action d'orchestration à effectuer dans ledit réseau.
Ainsi, et d'une façon générale, l'invention propose un procédé et un dispositif de gestion configurés pour déterminer si une action d'orchestration effectuée par une entité d'orchestration dans un réseau logiciel a pour effet d'améliorer ou de dégrader l'état du réseau. Ce dispositif de gestion calcule une valeur dite de réputation représentative de cette amélioration ou de cette dégradation et la communique à l'entité d'orchestration.
L'entité d'orchestration utilise cette valeur de réputation pour sélectionner les futures actions d'orchestration qu'elle effectue dans le réseau logiciel. Ces valeurs de réputation servent ainsi de retour (en anglais feedback) aux entités d'orchestration sur l'impact de leurs actions d'orchestration sur l'état du réseau et leur permettent d'adapter ces actions d'orchestration en conséquence.
Des exemples d'actions d'orchestration sont donnés dans le document « ETSI GS NFV-IFA 010 V2.2.1 (2016-09), Network Functions Virtualisation (NFV), Management and Orchestration, Functional requirements spécification ». A titre d'exemples :
- l'orchestrateur NFVO coordonne l'attribution des ressources matérielles, par exemple en réservant ou en libérant des ressources physiques matérielles du centre de données (datacenter). L'orchestrateur NFVO peut par exemple prendre une action d'orchestration pour choisir ne pas utiliser ou libérer une VNF en panne ou surchargée ;
- le gestionnaire VNFM créé, maintient et libère les instances des fonctions virtuelles VNF : création, mise à l'échelle, maintenance et libération des instances des VNF. Le gestionnaire VNFM peut par exemple prendre une action d'orchestration pour ajouter une instance d'une VNF;
- le gestionnaire VIM gère l'allocation, l'ajout, la libération et la récupération des ressources de l'infrastructure NFVI (stockage, CPU, cartes réseau, mémoires, ...) ainsi que leur optimisation. Le gestionnaire VIM peut par exemple prendre une action d'orchestration pour allouer des ressources de calcul aux machines virtuelles ;
- un contrôleur SDN peut par exemple prendre une action d'orchestration pour configurer un nouveau chemin réseau pour l'acheminement des paquets lorsqu'il détecte qu'un chemin en cours d'utilisation est en panne ou congestionné. Il est usuel dans ce contexte de définir par « résilience » la capacité d'une entité d'orchestration ou d'un système à répondre et à compenser des déviations d'état du réseau en appliquant des actions d'orchestration pour revenir d'un état du réseau dégradé par une perturbation à un état de référence connu et stable.
De façon particulièrement remarquable, l'invention propose une solution pour améliorer la résilience des entités d'orchestration par la mise en place d'un mécanisme de réputation qui évalue l'impact des actions de d'orchestration exécutées par ces entités en termes de déviation sur la résilience du réseau.
Le dispositif de gestion est typiquement mis en oeuvre dans une fonction centrale du réseau logiciel pour gérer l'ensemble des entités d'orchestration, comme notamment les contrôleurs SDN et les fonctions de gestion et d'orchestration MANO (NFVO, VNFM, VIM) mentionnées précédemment.
Comme mentionné précédemment, l'état du réseau peut être défini par un état du service et par un état d'au moins une couche opérationnelle permettant la mise en oeuvre de ce service.
L'état du service peut être obtenu à partir de métriques décrivant le service à différents instants de la fenêtre de temps. A titre d'exemple, on peut utiliser :
- une métrique de latence ;
- une métrique de gigue ;
- une métrique de bande passante ;
- un nombre d'appels échoués, etc.
En ce qui concerne l'état de la ou des couches opérationnelles, on peut par exemple utiliser (i) un état d'une couche de ressources matérielles et logicielles et/ou (ii) un état d'une couche de ressources virtuelles dudit réseau.
L'état d'une couche opérationnelle dans une fenêtre de temps est par exemple obtenu à partir de métriques décrivant cette couche à différents instants de cette fenêtre de temps.
A titre d'exemple, des métriques opérationnelles utilisées pour décrire une couche de ressources matérielles et logicielles à un instant donné peuvent comprendre :
- des métriques relatives à l'occupation ou aux statuts de CPUs ;
- des métriques relatives à l'occupation ou aux statuts de mémoires ;
- des métriques relatives à l'occupation ou aux statuts de disques ; et
- des métriques relatives à l'occupation ou aux statuts de ressources réseau.
De même, toujours à titre d'exemple, des métriques opérationnelles utilisées pour décrire une couche de ressources virtuelles à un instant donné peuvent comprendre :
- des métriques relatives à l'occupation ou aux statuts de fonctions CPU virtualisées ;
- des métriques relatives à l'occupation ou aux statuts de fonctions mémoire virtualisées ;
- des métriques relatives à l'occupation ou aux statuts de fonction disque virtualisées ; et
- des métriques relatives à l'occupation ou aux statuts de fonction réseau virtualisées. Dans un mode de réalisation de l'invention, l'état du réseau est calculé par un système à base d'apprentissage prenant en entrée les métriques de service et au moins un sous-ensemble des métriques d'au moins une couche opérationnelle.
Dans un mode de réalisation de l'invention, la couche opérationnelle (couche des ressources matérielles et logicielles ou couche des ressources virtuelles) est décrite à partir des métriques d'un seul groupe de ressources.
Il peut par exemple s'agir des métriques de type CPU, des métriques de type mémoire, des métriques de type disque ou des métriques de type ressource réseau.
En pratique, ce mode de réalisation est avantageux car une action d'orchestration vise généralement un seul groupe de ressources, par exemple, ajouter de la mémoire, effectuer une extensibilité CPU (en anglais scaling) verticale ou horizontale.
Dans un mode particulier de réalisation de l'invention, la valeur de réputation est augmentée ou diminuée selon que l'état du réseau se rapproche ou s'éloigne de l'état de référence par rapport à un état dans lequel se trouvait le réseau dans une fenêtre de temps antérieure à ladite fenêtre de temps.
Dans un mode particulier de réalisation, pour calculer une distance entre deux états du réseau, on représente ces états dans un espace bidimensionnel dans lequel une première dimension représente l'état du service et une deuxième dimension représente l'état de la couche opérationnelle qui rend ce service dans le réseau.
Un tel espace, connu sous le nom d'« espace de résilience » a été défini par Sterbenz et. al dans le document « Evaluation of network resilience, survivability, and disruption tolérance: analysis, topology génération, simulation, and expérimentation 2013-02. ».
L'invention concerne également un système comportant un dispositif de gestion et au moins une entité d'orchestration tels que mentionnés ci-dessus.
Les procédés de gestion et d'orchestration peuvent être mis en oeuvre par un programme d'ordinateur.
Par conséquent, l'invention vise également un programme d'ordinateur sur un support d'enregistrement, ce programme étant susceptible d'être mis en oeuvre dans un ordinateur, ce programme comporte des instructions permettant la mise en oeuvre d'un procédé de gestion ou la mise en oeuvre d'un procédé d'orchestration tels que décrits ci-dessus.
Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
L'invention vise aussi un support d'information ou un support d'enregistrement lisibles par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. Le support d'information ou d'enregistrement peut être n'importe quelle entité ou dispositif capable de stocker les programmes. Par exemple, les supports peuvent comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy dise) ou un disque dur, ou une mémoire flash.
D'autre part, le support d'information ou d'enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par lien radio, par lien optique sans fil ou par d'autres moyens.
Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.
Alternativement, le support d'informations ou d'enregistrement peut être un circuit intégré dans lequel un programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution de l'un des procédés tels que décrits précédemment.
On peut également envisager, dans d'autres modes de réalisation, que le procédé de gestion, le procédé d'orchestration, le dispositif de gestion, l'entité d'orchestration et le système selon l'invention présentent en combinaison tout ou partie des caractéristiques précitées.
Brève description des dessins
D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci- dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures :
[Fig. 1] la figure 1 déjà décrite représente un réseau logiciel conforme l'état de la technique ;
[Fig. 2] la figure 2 représente un système conforme à un mode particulier de réalisation de l'invention ;
[Fig. 3] la figure 3 représente des états successifs d'un réseau dans un espace de résilience ;
[Fig. 4] la figure 4 illustre l'effet d'une action d'orchestration;
[Fig. 5] la figure 5 illustre des distances entre des états dans un espace de résilience ;
[Fig. 6] la figure 6 illustre le calcul de réputations dans différentes situations;
[Fig. 7] la figure 7 représente les principales étapes mises en oeuvre par les modules, dispositifs et entités du système de la figure 2 dans un mode particulier de réalisation ;
[Fig. 8] la figure 8 représente l'architecture matérielle d'un dispositif de gestion conforme à un mode particulier de réalisation de l'invention ;
[Fig. 9] la figure 9 représente l'architecture fonctionnelle d'un dispositif de gestion conforme à un mode particulier de réalisation de l'invention ; [Fig. 10] la figure 10 représente l'architecture matérielle d'une entité d'orchestration conforme à un mode particulier de réalisation de l'invention ; et
[Fig. 11] la figure 11 représente l'architecture fonctionnelle d'une entité d'orchestration conforme à un mode particulier de réalisation de l'invention.
Description détaillée de modes de réalisation particuliers de l'invention
La figure 2 représente un système S conforme à un mode de réalisation de l'invention. Ce système est décrit dans le contexte de l'analyse d'un réseau virtualisé RV dans lequel un service SV est mis en oeuvre, ce service SV s'appuyant sur des fonctions réseau virtualisées VNF.
Dans le mode de réalisation décrit ici, l'état SSv ' de ce service SV, à un instant donné ti, peut être défini à partir d'un ensemble (ou conjoint) smsv ' de nSV métriques de service à cet instant ti, nSV désignant un entier supérieur ou égal à 1. On note smsv ' = [siri! 1',.··, sirinsv1'], l'ensemble des nSV métriques décrivant le service SVn à l'instant ti. Ces métriques de service comprennent par exemple :
- une métrique sirii11 de latence ;
- une métrique sm2 tl de gigue ;
- une métrique sms11 de bande passante ; ... et
- un nombre smnsv ' d'appels échoués.
Dans un mode de réalisation de l'invention, on utilise une fonction prédéterminée fsv pour estimer un état SSv ' du service SV à l'instant ti à partir des métriques smsv11. Autrement dit, dans ce mode de réalisation : Ssv1' = fsvCsnO = fsvCsmi11,..., sirinsv11)·
Les états Sa 1 du service SV calculés à différents instants ti permettent de définir un état SSvk du service SV dans une fenêtre de temps Tk. Cet état SSvk peut ici être qualifié de stable. Par exemple, SSvk est la moyenne des états Ssv11 du service SV calculés à différents instants ti de la fenêtre de temps Tk. En variante, d'autres fonctions statistiques que la moyenne, par exemple des fonctions de regréssion, peuvent être utilisées pour calculer un état SSvk du service pour la fenêtre de temps Tk à partir des états de service instantanés Sa 1.
Dans un mode de réalisation, la mise en oeuvre du service SV implique deux couches opérationnelles, à savoir :
- une couche opérationnelle LV de ressources virtuelles (machines virtuelles, containers, ...); et
- une couche opérationnelle LM de ressources matérielles et logicielles (serveurs, ...).
Chacune de ces couches opérationnelles LV, LM est décrite par un ensemble (ou conjoint) de métriques opérationnelles. On note :
- orriLM 11 = [omLM, 1,..., om^n 11], l'ensemble des nLM métriques opérationnelles décrivant la couche LM des ressources matérielles et logicielles à l'instant ti, nLM désignant un entier supérieur ou égal à 1 ; et - oh n ' = [OITILV,! 11,..., oh n,hi_n '], l'ensemble des nLV métriques opérationnelles décrivant la couche LV des ressources virtuelles à l'instant ti, nLV désignant un entier supérieur ou égal à 1.
Ces métriques instantanées sont mesurées sur les équipements de l'infrastructure physique de virtualisation NFVI.
A titre d'exemple, des métriques opérationnelles omLM i utilisées pour décrire la couche LM des ressources matérielles et logicielles à l'instant ti peuvent comprendre :
- des métriques relatives à l'occupation ou aux statuts de CPUs ;
- des métriques relatives à l'occupation ou aux statuts de mémoires ;
- des métriques relatives à l'occupation ou aux statuts de disques ; et
- des métriques relatives à l'occupation ou aux statuts de ressources réseau, d'équipements de l'infrastructure NFVI.
De même, toujours à titre d'exemple, des métriques opérationnelles oh n ' utilisées pour décrire la couche LV des ressources virtuelles à l'instant ti peuvent comprendre :
- des métriques relatives à l'occupation ou aux statuts de fonctions CPU virtualisées ;
- des métriques relatives à l'occupation ou aux statuts de fonctions mémoire virtualisées ;
- des métriques relatives à l'occupation ou aux statuts de fonction disque virtualisées ; et
- des métriques relatives à l'occupation ou aux statuts de fonction réseau virtualisées, des containers ou des machines virtuelles exécutées par des serveurs de l'infrastructure NFVI.
Dans un mode de réalisation de l'invention, on utilise une fonction prédéterminée fLM pour estimer un état SLM 11 de la couche opérationnelle LM des ressources matérielles et logicielles à l'instant ti à partir des métriques om^ . Autrement dit, dans ce mode de réalisation :
Figure imgf000011_0001
Les états SLM 11 de la couche opérationnelle LM des ressources matérielles et logicielles calculés à différents instants ti permettent de définir un état (qualifié de stable) SLM k de cette couche dans une fenêtre de temps Tk. Par exemple, SLM k est la moyenne des états SLM 11 de la couche LM calculés à différents instants ti de la fenêtre de temps Tk. En variante, d'autres fonctions statistiques que la moyenne, par exemple des fonctions de regréssion, peuvent être utilisées pour calculer un état SLM k de la couche LM pour la fenêtre de temps Tk à partir des états instantanés SLM 11·
Dans un mode de réalisation de l'invention, on utilise une fonction prédéterminée fLv pour estimer un état SLV 1 de la couche opérationnelle LV des ressources virtuelles à l'instant ti à partir des métriques OITILV 1. Autrement dit, dans ce mode de réalisation :
SLvU = fLv(omLv ') = ίΐL/(oh n,L..., oh n,hΐL/ H)
Les états SLV 11 de la couche opérationnelle LV des ressources virtuelles calculés à différents instants ti permettent de définir un état (qualifié de stable) SLvk de cette couche dans une fenêtre de temps Tk. Par exemple, SLvk est la moyenne des états SLV 11 de la couche LV calculés à différents instants ti de la fenêtre de temps Tk. En variante, d'autres fonctions statistiques que la moyenne, par exemple des fonctions de regréssion, peuvent être utilisées pour calculer un état SLvk de la couche LV pour la fenêtre de temps Tk à partir des états instantanés SLv '
Dans la suite de la description, on désignera par L une couche opérationnelle LM ou LV et par G les métriques d'un type de ressources particulières. Par exemple G peut prendre 4 valeurs C, M, D et N pour désigner des métriques relatives :
- à des ressources matérielles et logicielles de CPU de la couche LM ou à des fonctions CPU virtualisées de la couche LV (G=C) ;
- à des ressources matérielles et logicielles de disque de la couche LM ou à des fonctions disque virtualisées de la couche LV (G=D) ;
- à des ressources matérielles et logicielles de mémoire de la couche LM ou à des fonctions mémoire virtualisées de la couche LV (G=M) ;
- à des ressources matérielles et logicielles réseau de la couche LM ou à des fonctions réseau virtualisées de la couche LV (G=N).
Des exemples concrets de métriques CPU (G=C) sont par exemple :
- node_cpu_core_throttles_total{core="0",package="0"} (nombre de fois où la fréquence d'un CPU a été limitée pour éviter ou faire face à une surchauffe) ou
- node_cpu_scaling_frequency_hertz{cpu="4"} (valeur courante de la fréquence du quatrième cœur du CPU).
Dans un mode particulier de réalisation, l'invention propose de définir huit états du réseau logiciel Sk(G,L) dans la fenêtre de temps Tk, avec :
- G = C, D, M ou N ; et
- L = LM ou LV.
Ainsi et à titre d'exemple la notation Sk(N' LV) désigne un état du réseau logiciel défini par :
- l'état Ssvk du service SV dans la fenêtre de temps Tk, et
- un état SLvk de la couche opérationnelle des ressources virtuelles LV dans la fenêtre de temps Tk calculé à partir des métriques relatives aux fonctions réseau virtualisées.
Comme représenté à la figure 3, les états Sk, Sk+1, Sk+2 du réseau logiciel ((G,L) omis par souci de simplification) dans des fenêtres de temps successives Tk, Tk+1, Tk+2 peuvent être représentés dans un espace à deux dimensions dans lequel :
- la dimension DP (axe des ordonnées) représente l'état Ssvk du service SV ; et
- la dimension DN (axe des abscisses) représente un état opérationnel SL k d'une couche opérationnelle matérielle LM ou virtuelle LV qui rend ce service dans le réseau.
Sur cette figure 3, les flèches représentent des transitions du réseau entre deux états Sk, Sk+1, respectivement entre deux états Sk+1,Sk+2, de fenêtres de temps Tk, Tk+1 successives, respectivement de fenêtres de temps Tk+1, Tk+2 successives. De retour à la figure 2, le système S comporte un module MOM d'obtention des métriques du réseau virtualisé. Dans le mode de réalisation décrit ici, ce module MOM est configuré pour collecter, à différents instants ti :
- les métriques de service smsv ' ;
- les métriques om^1 de la couche opérationnelle des ressources matérielles LM ; et
- les métriques om^1 de la couche opérationnelle des ressources virtuelles LV.
Dans le mode de réalisation décrit ici, le système S comporte un module MOE d'obtention d'états Sk du réseau logiciel dans différentes fenêtres de temps Tk à partir des métriques de service smsv ' et des métriques opérationnelles om^1 et omi 11 collectées par le module MOM à différents instants ti dans ces fenêtres de temps Tk.
Dans un mode de réalisation de l'invention, le module MOE d'obtention d'états utilise des fonctions prédéterminées fs , Vi, fi_v pour calculer les états Ss k du service SV, les états SL k de la couche opérationnelle des ressources virtuelles LV et les états SLM k de la couche opérationnelle des ressources matérielles LM dans la fenêtre de temps Tk à partir des différentes métriques.
Ces fonctions fSv, Vi, fi_v sont par exemple des fonctions de classification aptes à effectuer une mise en correspondance (en anglais mapping) des métriques vers un état. Ainsi par exemple, la fonction fSv peut être une fonction apte à mettre en correspondance les métriques sm^1 avec un état de service Ssv1· Ces fonctions peuvent être implémentées sous forme de réseaux de neurones (en anglais neural network).
Dans un autre mode de réalisation, le module MOE d'obtention d'états utilise une méthode à base d'apprentissage (en anglais Machine Learning) ML qui prend en entrée les métriques oh M 11 et om^ 1 des couches opérationnelles LM et LV et les métriques smsv11 de service pour compresser ces métriques et calculer les états Sk du réseau à chaque fenêtre temporelle Tk.
Par exemple, cette méthode peut utiliser un auto-encoder et utiliser une erreur de reconstruction pour compresser les métriques omi 1', om^1 et smsv11 sur un seul indicateur Sk.
En variante, cette méthode peut combiner une technique de réduction de la dimensionnalité, par exemple la méthode PCA (en anglais Principal Component Analysis) et une technique de regroupement (en anglais clustering) pour projeter les métriques sur un espace bidimensionnel, reconnaître les groupements (en anglais clusters) des métriques et définir les états à partir de ces groupements.
Dans un mode particulier de réalisation, le module MOE d'obtention d'états peut calculer les états successifs Sk(G,L) (et les transitions) pour chaque couche opérationnelle L (LM ou LV) et pour chaque groupe G de métriques C, D, M et N (CPU, disque, mémoire et réseau).
Dans le mode de réalisation décrit ici, le module MOE d'obtention d'états enregistre les états Sk ou Sk(G,L) dans une mémoire tampon MT (en anglais buffer). La figure 4 illustre, d'une façon générale, un objectif visé par les entités d'orchestration EO (NFVO, VNFM, VIM, T-SDN, I-SDN).
Cette figure représente, dans un espace de résilience du type de celui de la figure 3, un état SR du réseau considéré comme un état de référence et un état Sk dégradé de ce réseau. L'écart entre ces états SR et Sk peut être qualifié de déviation D ; il est représenté par une flèche à trait plein sur la figure 4.
Un rôle des entités d'orchestration EO est de mettre en place une ou plusieurs actions d'orchestration pour compenser une telle déviation d'état D, de manière à ce que le réseau revienne ou tende à revenir de son état dégradé Sk à son état de référence SR comme illustré par la flèche en traits pointillés sur la figure 4.
Par exemple, une entité d'orchestration comme le VIM, qui gère des machines virtuelles pourra observer que le niveau de CPU est insuffisant (état dégradé) et appliquer une action d'orchestration d'extensibilité verticale ou horizontale.
Dans le mode de réalisation décrit ici, chaque entité d'orchestration EO enregistre dans la mémoire tampon MT une indication IAk si elle a mis en oeuvre une ou plusieurs actions d'orchestration Ak pendant la fenêtre de temps Tk. Sur la figure 2, on note :
- IA SDN une indication qu'une ou plusieurs actions ont été effectuées par le contrôleur T-SDN;
- IAYSDN une indication qu'une ou plusieurs actions ont été effectuées par le contrôleur I-SDN ;
- IAk NFVo une indication qu'une ou plusieurs actions ont été effectuées par l'orchestrateur NFVO ;
- IAVNFM une indication qu'une ou plusieurs actions ont été effectuées par le gestionnaire VNFM ;
- IAk ViM une indication qu'une ou plusieurs actions ont été effectuées par le gestionnaire VIM pendant la fenêtre de temps Tk.
Dans le mode de réalisation décrit ici, le système S comporte un dispositif TRM de gestion configuré pour obtenir à partir de la mémoire tampon MT :
- les états Sk ou sk(G,L) du réseau logiciel publiés par le module MOE d'obtention d'états du réseau pendant une fenêtre de temps Tk ; et
- les indications IAk que des actions ont été effectuées par les entités d'orchestration EO pendant cette fenêtre de temps Tk.
Dans un mode particulier de réalisation de l'invention, lorsque le module TRM de gestion reçoit l'information selon laquelle le réseau logiciel est, dans une fenêtre de temps Tk, dans un état dégradé Sk et qu'il prend connaissance qu'une entité d'orchestration EO a effectué une action pendant cette fenêtre de temps Tk, le module TRM envoie à cette entité d'orchestration EO une valeur de réputation rEO k inversement proportionnelle à la distance entre la représentation de l'état SR de référence la représentation de l'état dégradé Sk dans l'espace de résilience de la figure 4.
Dans un mode particulier de réalisation de l'invention, le module TRM utilise un modèle de réputation tel que la valeur de réputation rEok est difficile à gagner mais facile à perdre, pour décourager les actions d'orchestration Ak des entités d'orchestration EO qui éloignent l'état du système de l'état de référence SR et qui aggravent les pannes en ayant un impact négatif sur le réseau. Ainsi, la réputation rEO k d'une entité d'orchestration EO qui éloigne l'état courant de l'état de référence SR, doit chuter brutalement, diminuer considérablement ou devenir relativement basse. Au contraire, lorsque une action d'orchestration Ak rapproche l'état Sk de l'état de référence SR ou le maintien autour de cet état de référence, l'entité d'orchestration EO à l'origine de cette action Ak doit être récompensée par le dispositif de gestion TRM par une valeur de réputation rEok en légère hausse, ou relativement élevée.
Dans un autre mode de réalisation décrit en référence à la figure 5, ladite valeur de réputation rEO k est augmentée ou diminuée selon que ledit état Sk du réseau se rapproche ou s'éloigne dudit état de référence SR par rapport à un état Sk l du réseau dans une fenêtre de temps Tk l antérieure à ladite fenêtre de temps Tk.
Par exemple, en notant ;
- dk la distance entre l'état de référence SR ;et
- rEO k la valeur de réputation calculée pour la fenêtre de temps Tk ; on peut définir rEO k = rEO k l.dk l/dk.
Dans un autre mode de réalisation décrit en référence aux figures 6A à 6D, on considère deux types de transition entre des états du réseau logiciel, à savoir :
- des transitions dites « spontanées » (référencées D?) lorsque le réseau subit une dégradation qui ne peut pas être attribuée à une entité d'orchestration EO, par exemple en raison d'une panne ou d'un mauvais usage d'un équipement. Le module TRM considère qu'une transition qui se produit dans une fenêtre de temps Tk est spontanée si ce module TRM ne reçoit aucune indication IAk d'une action d'orchestration Ak pour cette fenêtre de temps ; et
- des transitions dites « non spontanées » (référencées DAk) dans lequel le réseau bascule d'un état Sk l à un nouvel état Sk en raison d'une action d'orchestration Ak effectuée par une entité d'orchestration EO, cette action pouvant avoir un impact positif (Sk se rapproche de l'état de référence SR par rapport à Sk l) ou négatif (Sk s'éloigne de l'état de référence SR par rapport à Sk l) sur le réseau.
Dans ce mode de réalisation et comme représenté à la figure 6, on note :
- DAkN la composante de DAk selon l'axe des abscisses DN ; et
- DAkP la composante de DAk selon l'axe des ordonnées DP.
Dans la situation de la figure 6A, les composantes DAkN et DAkP sont positives. Dans le mode de réalisation décrit ici, le module TRM envoie à l'entité d'orchestration EO ayant effectué l'action Ak une valeur de réputation rEO k négative et proportionnelle à DAkP et inversement proportionnelle à D?, D? désignant également la distance entre SR et Sk l. Dans la situation de la figure 6B, la composante DAkN est négative et la composante DAkP est positive. Dans le mode de réalisation décrit ici, le module TRM envoie à l'entité d'orchestration EO ayant effectué l'action Ak une valeur de réputation rEO k négative et proportionnelle à DAkP/D?.
Dans la situation de la figure 6C, la composante DAkN est positive et la composante DAk est négative. Dans le mode de réalisation décrit ici, le module TRM envoie à l'entité d'orchestration EO ayant effectué l'action Ak une valeur de réputation rEO k négative et proportionnelle à DAkN/D?.
Dans la situation de la figure 6D, les composantes DAkN et DAk sont négatives. Dans le mode de réalisation décrit ici, le module TRM envoie à l'entité d'orchestration EO ayant effectué l'action Ak une valeur de réputation rEO k positive et proportionnelle à DAk et inversement proportionnelle à D?.
Comme représenté à la figure 2, dans le mode de réalisation décrit ici, les entités d'orchestration EO reçoivent les valeurs de réputation rEO k du module TRM. On note par exemple, rViM k la valeur de réputation que le module TRM envoie au gestionnaire VIM.
Dans le mode de réalisation décrit ici, au début de la mise en place du service SV, chaque entité d'orchestration EO a une valeur de réputation rE0 nulle. Puis, au fur et à mesure qu'une entité d'orchestration EO effectue des actions d'orchestration Ak, cette entité EO reçoit du module TRM des valeurs de réputation rEO k qui permettent à cette entité d'orchestration EO de comprendre si les actions d'orchestration Ak effectuées dans le but de corriger un état dégradé du réseau sont effectivement efficaces pour ramener le réseau dans ou vers son état de référence SR.
Autrement dit, ces valeurs de réputation rEO k servent de retour (en anglais feedback) aux entités d'orchestration sur l'impact de leurs actions d'orchestration.
Dans le mode de réalisation décrit ici, les entités d'orchestration EO utilisent les valeurs de réputation rEO k pour optimiser et/ou corriger leurs futures actions d'orchestration afin de mieux réagir aux futures dégradations.
Ainsi, dans le mode de réalisation décrit ici, chaque entité d'orchestration EO comporte un agent RL configuré pour mettre en oeuvre une méthode d'apprentissage par renforcement (en anglais Reinforcement Learning ou RL). Cet agent RL reçoit en entrée les valeurs de réputation rEO k et sélectionne en sortie les actions d'orchestration adaptées pour réagir à une dégradation donnée.
Le principe d'une telle méthode d'apprentissage par renforcement est connu de l'homme de l'art. En l'espèce, elle pourrait mettre en oeuvre un algorithme d'apprentissage par renforcement pour réaliser une transition de l'état courant vers un état cible sur la base d'un signal de retour (en anglais feedback) généré suite à une action d'orchestration.
Dans le mode de réalisation décrit ici, la prise en compte de ces valeurs de réputation rEOk permet :
- à l'orchestrateur NFVO d'améliorer sa gestion du cycle de vie des services réseau
- au gestionnaire VNFM d'améliorer la prise en charge du cycle de vie des VNFs ;
- au gestionnaire VIM d'améliorer le placement des machines virtuelles et la gestion de leurs cycles de vie ; - aux contrôleurs T-SDN et I-SDN d'améliorer le parcours d'acheminement de trafic, chacun à leur niveau. Le I-SDN gère les connections entre les VNFs et le T-SDN peut contrôler le trafic au niveau tenant étant vu comme une autre fonction réseau (VNF). Sur ce point, l'homme du métier pourra se reporter au document « Network Slicing for 5G with SDN/NFV: Concepts, Architectures and Challenges, Ordonez et al, March 2017, IEEE Communications Magazine 55(5) ».
La figure 7 représente les principales étapes mises en oeuvre par les modules, dispositifs et entités du système de la figure 2 dans un mode particulier de réalisation. Les étapes mises en oeuvre par le dispositif de gestion TRM constituent un exemple de procédé de gestion conforme à l'invention. De même, les étapes mises en oeuvre par l'entité d'orchestration EO constituent un exemple de procédé d'orchestration conforme à l'invention.
Au cours d'une étape E10, le module MOM d'obtention obtient à différents instants ti :
- les métriques de service srrisv ' ;
- les métriques OITILM11 de la couche opérationnelle des ressources matérielles LM ; et
- les métriques oh n11 de la couche opérationnelle des ressources virtuelles LV.
Le module MOM communique ces métriques au module MOE d'obtention d'états au cours d'une étape E20.
Au cours d'une étape E30, le module MOE d'obtention d'états calcule les états Sk du réseau pour différentes fenêtres de temps Tk. Il utilise par exemple une méthode à base d'apprentissage qui prend en entrée les métriques oh M 11 et om^ 1 des couches opérationnelles LM et LV et les métriques smsv11 de service.
Le module MOE communique les états Sk du réseau au dispositif de gestion TRM au cours d'une étape E40.
Au cours d'une étape générale E50, une entité d'orchestration EO décide des actions d'orchestration à effectuer dans le réseau logiciel. Elle effectue l'action Ak au cours d'une étape E60. Au cours d'une étape E70 elle envoie au dispositif de gestion TRM une indication IAEok selon laquelle elle a effectué au moins une action d'orchestration pendant la fenêtre de temps Tk.
Au cours d'une étape E80, le dispositif de gestion TRM calcule une valeur de réputation rEok pour la fenêtre de temps Tk et l'entité d'orchestration EO. Cette valeur de réputation rEO k représente le fait que l'état Sk du réseau a été amélioré ou dégradé par l'action Ak effectuée par l'entité d'orchestration EO.
Le dispositif de gestion TRM envoie la valeur de réputation rEO k à l'entité d'orchestration EO au cours d'une étape E90.
Au cours d'une étape E100, l'entité d'orchestration EO injecte cette valeur de réputation rEO k dans son système d'apprentissage RL. Elle sera prise en compte au cours d'une itération ultérieure de l'étape E50 pour sélectionner une future action d'orchestration. La figure 8 représente l'architecture matérielle d'un dispositif de gestion TRM conforme à un mode particulier de réalisation de l'invention. Dans le mode de réalisation décrit ici, ce dispositif a l'architecture matérielle d'un ordinateur. Il comporte un processeur 10, des moyens de communication 11 sur un réseau, une mémoire vive de type RAM 12, une mémoire non volatile réinscriptible 13 et une mémoire morte 14. La mémoire morte constitue un support d'informations pour stocker un programme d'ordinateur PG-TRM conforme à l'invention. Lorsque le processeur 10 exécute ce programme d'ordinateur, il met en oeuvre le procédé de gestion décrit en référence à la figure 7.
La figure 9 représente l'architecture fonctionnelle d'un dispositif de gestion TRM conforme à un mode particulier de réalisation de l'invention. Ce dispositif peut être implémenté de façon matérielle comme illustré à la figure 8. Il comporte :
- un module M70 d'obtention d'une indication IAk selon laquelle une entité d'orchestration EO a effectué au moins une action d'orchestration Ak dans le réseau au cours d'une fenêtre de temps (Tk) ;
- un module M40 d'obtention d'au moins un état Sk du réseau dans ladite fenêtre de temps Tk, ledit état Sk du réseau comportant un état SSvk d'un service mis en oeuvre dans le réseau et un état SL K d'au moins une couche opérationnelle du réseau pour la mise en oeuvre de ce service SV ;
- un module M80 d'obtention, à partir dudit état du réseau Sk et d'un état SR de référence dudit réseau, d'une valeur de réputation rEok représentative d'une amélioration ou d'une dégradation de l'état du réseau ; et
- un module M90 d'envoi de la valeur de réputation rEok à l'entité d'orchestration (EO).
La figure 10 représente l'architecture matérielle d'une entité d'orchestration EO conforme à un mode particulier de réalisation de l'invention. Dans le mode de réalisation décrit ici, cette entité EO a l'architecture matérielle d'un ordinateur. Elle comporte un processeur 20, des moyens de communication 21 sur un réseau, une mémoire vive de type RAM 22, une mémoire non volatile réinscriptible 23 et une mémoire morte 24. La mémoire morte constitue un support d'informations pour stocker un programme d'ordinateur PG-EO conforme à l'invention. Lorsque le processeur 20 exécute ce programme d'ordinateur, il met en oeuvre le procédé d'orchestration décrit en référence à la figure 7.
La figure 11 représente l'architecture fonctionnelle d'une entité d'orchestration EO conforme à un mode particulier de réalisation de l'invention. Cette entité peut être implémentée de façon matérielle comme illustré à la figure 10. Elle comporte :
- un module M700 d'envoi, à un dispositif TRM de gestion, d'une indication IAk selon laquelle ladite entité d'orchestration EO a effectué au moins une action d'orchestration Ak dans ledit réseau au cours d'une fenêtre de temps Tk ;
- un module M900 de réception d'une valeur de réputation rEO k en provenance dudit dispositif de gestion TRM ;
- un module M500 de sélection d'une action d'orchestration, ce modulé étant configuré pour prendre en compte ladite valeur de réputation rEO k pour sélectionner une action d'orchestration à effectuer dans le réseau.

Claims

REVENDICATIONS
[Revendication 1] Procédé de gestion d'au moins une entité d'orchestration (EO) dans un réseau logiciel, ce procédé étant mis en oeuvre par un dispositif (TRM) de gestion de ladite au moins une entité d'orchestration (EO) et comportant :
- une étape (E70) d'obtention, en provenance de ladite entité d'orchestration (EO), d'une indication (IAk) selon laquelle ladite entité d'orchestration (EO) a effectué au moins une action d'orchestration (Ak) dans ledit réseau au cours d'une fenêtre de temps (Tk) ;
- une étape (E40) d'obtention d'au moins un état (Sk) du réseau dans ladite fenêtre de temps (Tk), ledit état (Sk) du réseau comportant un état (SSvk) d'un service mis en oeuvre dans le réseau et un état (SL K) d'au moins une couche opérationnelle du réseau pour la mise en oeuvre dudit service (SV) ;
- une étape (E80) d'obtention, à partir dudit état du réseau (Sk) et d'un état (SR) de référence dudit réseau, d'une valeur de réputation (rEO k) représentative d'une amélioration ou d'une dégradation d'un état du réseau (Sk) ; et
- une étape (E90) d'envoi de ladite valeur de réputation (rEO k) à ladite entité d'orchestration (EO).
[Revendication 2] Procédé de gestion selon la revendication 1 dans lequel ladite au moins une couche opérationnelle est une couche (LM) de ressources matérielles et logicielles ou une couche (LV) de ressources virtuelles dudit réseau, ledit état (SL K) de ladite au moins une couche opérationnelle étant obtenu (E30) à partir de métriques (OITILM11, omLv ') décrivant ladite couche (LM, LV) à différents instants de ladite fenêtre de temps (Tk).
[Revendication 3] Procédé de gestion selon la revendication 2 dans lequel ladite couche opérationnelle est décrite à partir des métriques d'un seul groupe de ressources choisi parmi des métriques de type CPU, des métriques de type mémoire, des métriques de type disque ou des métriques de type réseau.
[Revendication 4] Procédé de gestion selon l'une quelconque des revendications 1 à 3 dans lequel ledit état (Ss K) dudit service (SV) est obtenu (E30) à partir de métriques (stria/1) décrivant ledit service à différents instants de ladite fenêtre de temps (Tk).
[Revendication 5] Procédé de gestion selon les revendications 2 à 4 caractérisé en ce que ledit état (Sk) du réseau est calculé (E30) par un système à base d'apprentissage prenant en entrée lesdites métriques (OITW, omLv ', stria ).
[Revendication 6] Procédé de gestion selon l'une quelconque des revendications 1 à 5, caractérisé en ce que ladite valeur de réputation (rEO k) est augmentée ou diminuée (E80) selon que ledit état (Sk) du réseau se rapproche ou s'éloigne dudit état de référence (SR) par rapport à un état (Sk l) du réseau dans une fenêtre de temps (Tk l) antérieure à ladite fenêtre de temps (Tk).
[Revendication 7] Procédé de gestion selon la revendication 6 dans lequel pour calculer une distance entre deux états (SR, Sk l, Sk) du réseau, on représente ces états dans un espace bidimensionnel dans lequel une première dimension représente ledit état (SSvk) du service et une deuxième dimension représente ledit état (SL K) de ladite au moins une couche opérationnelle.
[Revendication 8] Dispositif (TRM) de gestion d'au moins une entité d'orchestration (EO) dans un réseau logiciel, ce dispositif comportant :
- un module (M70) d'obtention d'une indication (IAk) selon laquelle ladite entité d'orchestration (EO) a effectué au moins une action d'orchestration (Ak) dans ledit réseau au cours d'une fenêtre de temps (Tk) ;
- un module (M40) d'obtention d'au moins un état (Sk) du réseau dans ladite fenêtre de temps (Tk), ledit état (Sk) du réseau comportant un état (SSvk) d'un service mis en oeuvre dans le réseau et un état (SL K) d'au moins une couche opérationnelle du réseau pour la mise en oeuvre dudit service (SV) ;
- un module (M80) d'obtention, à partir dudit état du réseau (Sk) et d'un état (SR) de référence dudit réseau, d'une valeur de réputation (rEok) représentative d'une amélioration ou d'une dégradation d'un état du réseau (Sk) ; et
- un module (M90) d'envoi de ladite valeur de réputation (rEok) à ladite entité d'orchestration (EO).
[Revendication 9] Procédé d'orchestration mis en oeuvre par une entité d'orchestration (EO) dans un réseau logiciel, le procédé comportant :
- une étape (E70) d'envoi, à un dispositif (TRM) de gestion, d'une indication (IAk) selon laquelle ladite entité d'orchestration (EO) a effectué au moins une action d'orchestration (Ak) dans ledit réseau au cours d'une fenêtre de temps (Tk) ;
- une étape (E90) de réception d'une valeur de réputation (rEO k) obtenue par ledit dispositif (TRM) de gestion en mettant en oeuvre un procédé de gestion selon l'une quelconque des revendications 1 à
7 ; et
- une étape (E50) de prise en compte de ladite valeur de réputation (rEO k) pour sélectionner une action d'orchestration à effectuer dans ledit réseau.
[Revendication 10] Entité d'orchestration (EO) comportant :
- un module (M700) d'envoi, à un dispositif (TRM) de gestion selon la revendication 8 d'une indication (IAk) selon laquelle ladite entité d'orchestration (EO) a effectué au moins une action d'orchestration (Ak) dans ledit réseau au cours d'une fenêtre de temps (Tk) ;
- un module (M900) de réception d'une valeur de réputation (rEO k) en provenance dudit dispositif de gestion (TRM) ; et
- un module (M500) de sélection d'une action d'orchestration configuré pour prendre en compte ladite valeur de réputation (rEO k) pour sélectionner une action d'orchestration à effectuer dans ledit réseau.
[Revendication 11] Système (S) comportant :
- un dispositif (TRM) de gestion selon la revendication 8 ;
- au moins une entité d'orchestration (EO) selon la revendication 10.
[Revendication 12] Programme d'ordinateur (PG-TRM) comportant des instructions pour la mise en oeuvre d'un procédé de gestion selon l'une quelconque des revendications 1 à 7 lorsque le programme est exécuté par un ordinateur.
[Revendication 13] Programme d'ordinateur (PG-EO) comportant des instructions pour la mise en oeuvre d'un procédé d'orchestration selon la revendication 9 lorsque le programme est exécuté par un ordinateur. [Revendication 14] Support d'enregistrement comprenant un programme d'ordinateur (PG-TRM, PG-EO) selon la revendication 12 ou 13.
PCT/FR2022/051332 2021-07-05 2022-07-04 Gestion d'au moins une entite d'orchestration dans un reseau logiciel WO2023281200A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP22750865.2A EP4367857A1 (fr) 2021-07-05 2022-07-04 Gestion d'au moins une entité d'orchestration dans un réseau logiciel

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2107239A FR3124913B1 (fr) 2021-07-05 2021-07-05 Procédé de gestion d’au moins une entité d’orchestration dans un réseau logiciel
FRFR2107239 2021-07-05

Publications (1)

Publication Number Publication Date
WO2023281200A1 true WO2023281200A1 (fr) 2023-01-12

Family

ID=77411885

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2022/051332 WO2023281200A1 (fr) 2021-07-05 2022-07-04 Gestion d'au moins une entite d'orchestration dans un reseau logiciel

Country Status (3)

Country Link
EP (1) EP4367857A1 (fr)
FR (1) FR3124913B1 (fr)
WO (1) WO2023281200A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9985866B1 (en) * 2016-07-23 2018-05-29 Sprint Communications Company L.P. Task performance with virtual probes in a network function virtualization (NFV) software defined network (SDN)
US10341195B1 (en) * 2016-06-29 2019-07-02 Sprint Communications Company L.P. Virtual network function (VNF) resource management in a software defined network (SDN)
WO2021090133A1 (fr) * 2019-11-08 2021-05-14 Telefonaktiebolaget Lm Ericsson (Publ) Obtention de disponibilité de services demandée

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10341195B1 (en) * 2016-06-29 2019-07-02 Sprint Communications Company L.P. Virtual network function (VNF) resource management in a software defined network (SDN)
US9985866B1 (en) * 2016-07-23 2018-05-29 Sprint Communications Company L.P. Task performance with virtual probes in a network function virtualization (NFV) software defined network (SDN)
WO2021090133A1 (fr) * 2019-11-08 2021-05-14 Telefonaktiebolaget Lm Ericsson (Publ) Obtention de disponibilité de services demandée

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ORDONEZ ET AL.: "Network Slicing for 5G with SDN/NFV: Concepts, Architectures and Challenges", IEEE COMMUNICATIONS MAGAZINE, vol. 55, no. 5, March 2017 (2017-03-01)

Also Published As

Publication number Publication date
EP4367857A1 (fr) 2024-05-15
FR3124913B1 (fr) 2024-03-15
FR3124913A1 (fr) 2023-01-06

Similar Documents

Publication Publication Date Title
US11316755B2 (en) Service enhancement discovery for connectivity traits and virtual network functions in network services
Aral et al. Addressing application latency requirements through edge scheduling
US20210273884A1 (en) Adaptive overlay network architecture
US10104442B2 (en) Social delivery of IPTV streams
WO2016001502A1 (fr) Orchestration de ressources physiques et virtuelles pour la livraison de contenus numériques
US9197687B2 (en) Prioritized blocking of on-demand requests
EP3053326B1 (fr) Procédé d'accès d'un utilisateur a au moins un service de communication fourni par l'intermédiaire d'un centre informatique d'un système d'informatique en nuage
Xia et al. A Social Network Under Social Distancing:{Risk-Driven} Backbone Management During {COVID-19} and Beyond
FR2804808A1 (fr) Procede d'optimisation dynamique de la qualite de service dans un reseau de transmission de donnees
EP4367857A1 (fr) Gestion d'au moins une entité d'orchestration dans un réseau logiciel
WO2016198762A1 (fr) Procédé et système de détermination d'une configuration de serveurs cible pour un déploiement d'une application logicielle
WO2020260025A1 (fr) Procede d'allocation de ressources d'une infrastructure de reseau
Hoßfeld et al. Quality of experience management for youTube: clouds, foG and the aquareYoum
EP3807760B1 (fr) Procédé d'installation d'une fonction réseau virtualisée
Herbaut et al. Dynamic deployment and optimization of virtual content delivery networks
EP2103055B1 (fr) Procédé d'optimisation du partage d'une pluralité de ressources réseau entre une pluralité de flux applicatifs
EP3854136B1 (fr) Procédé de réattribution d'un serveur périphérique de traitement de données
Montero et al. Actuation framework for 5G-enabled network slices with QoE/QoS guarantees
WO2010089316A1 (fr) Procede de gestion des echanges de flux de donnees dans un reseau de telecommunication autonomique
EP2669799A1 (fr) Méthode et système pour l'approvisionnement d'un service basée sur des logiciels
Frigui Autonomic maintenance of high programmable optical access network
US20240114347A1 (en) Dynamic radio access network sharing
US20240039811A1 (en) Optimizing application experience in hybrid work environments
WO2024107564A1 (fr) Techniques de récupération de données d'application à utiliser dans une sélection de chemin
WO2023163776A1 (fr) Ingénierie de trafic sensible aux performances de bout en bout pour homologation internet

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22750865

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2022750865

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2022750865

Country of ref document: EP

Effective date: 20240205