Search

EP-3967000-B1 - METHOD AND NODE FOR USING TEMPLATES

EP3967000B1EP 3967000 B1EP3967000 B1EP 3967000B1EP-3967000-B1

Inventors

  • BLAU, STAFFAN
  • BJÖRKQVIST, Magnus

Dates

Publication Date
20260513
Application Date
20200507

Claims (20)

  1. A method performed by a node for handling a management operation, the method comprising: receiving (S200) from an orchestration node, a Life Cycle Management, LCM, request for an operation related to virtual network function operation, the LCM request comprising a first parameter; characterized by mapping (240) the first parameter received in the LCM request to a second parameter comprised in a cloud native template; and invoking (S260) an orchestration command comprising the mapped second parameter related to the cloud native template, wherein mapping the first parameter is performed using a script mapping the first parameter to the second parameter.
  2. The method according to claim 1, wherein the script is fetched from a Virtual Network Function, VNF, software package.
  3. The method according to any of the claims 1-2, wherein the script comprises the node calling the script.
  4. The method according to any of the claims 1-3, wherein input to the script is at least one of information from the request received from the orchestration node, information from a request for grant, and information from a response to the request for grant.
  5. The method according to any of the claims 1-4, wherein output from the script comprises input parameter key-value pairs for the cloud native template.
  6. The method according to any of the claims 1-5, wherein mapping the first parameter comprises using a name correlation scheme, seeing to that the first parameter in a Topology and Orchestration Specification for Cloud Applications, TOSCA, Virtualized Network Function Descriptor, VNFD, is derived from the second parameter in the cloud native template.
  7. The method according to any of the claims 1-6, wherein the first parameter comprises information from the request, and the second parameter comprises input parameter key-value pairs for cloud native template specified inputs that need values specific to the management operation.
  8. The method according to any of the claims 1-7, wherein the first parameter comprises virtual resource parameters that are not statically defined in a Virtualized Network Function Descriptor, VNFD.
  9. The method according to any of the claims 1-8, further comprising computing (S210) resource changes to be performed.
  10. The method according to any of the claims 1-9, wherein the request relates to adding, changing or removing virtual resources.
  11. The method according to any of the claims 1-10, further comprising sending (S220) a request for grant to the orchestration node.
  12. The method according to claims 9 and 11, wherein the request for grant includes information associated with the computed (S210) resource changes.
  13. The method according to any of the claims 11-12, further comprising receiving (S230) a response indicating a grant to the sent (S220) request for grant.
  14. The method according to any of the claims 1-13, wherein the orchestration command is a cloud native template orchestration Application Programming Interface, API, command.
  15. The method according to any of the claims 1-14, wherein the node is a Virtualized Network Function Manager, VNFM.
  16. The method according to any of the claims 1-15, wherein the orchestration node is a Network Function Virtualization Orchestrator, NFV-O.
  17. The method according to any of the claims 1-16, wherein input to the orchestration command comprises at least one of cloud native orchestration template input parameters, and the cloud native template.
  18. The method according to claim 17, wherein the cloud native orchestration template input parameters comprise key-value pairs for the cloud native template.
  19. The method according to any of the claims 1-18, further comprising: sending (S270) a notification to the orchestration node, wherein the notification comprises the list of virtual resources.
  20. The method according to any of the claims 1-19, further comprising: interacting (S280) with a Virtualization Infrastructure Manager, VIM, to get a list of virtual resources deployed for a Virtual Network Function.

Description

TECHNICAL FIELD Embodiments herein relate to a node, and a method performed therein for communication. In particular, embodiments herein relate to handling Network Function Virtualization. BACKGROUND Generally, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and/or is implied from the context in which it is used. All references to a/an/the element, apparatus, component, means, step, etc. are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any methods disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and/or where it is implicit that a step must follow or precede another step. Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, wherever appropriate. Likewise, any advantage of any of the embodiments may apply to any other embodiments, and vice versa. Other objectives, features, and advantages of the enclosed embodiments will be apparent from the following description. In the European Telecommunications Standards Institute (ETSI) Network Functions Virtualization (NFV)- Management and Orchestration (MANO) architecture (see Fig. 1) for orchestration and life-cycle management of virtualized networks and Virtualized Network Functions (VNF), the VNF Manager (VNFM) entity handles the interaction with the native Virtualization Infrastructure Manager (VIM) in the cloud on which one deploys VNF applications. Fig. 1 shows the NFV-MANO architectural components and what ETSI specifications that relates to the different components and interfaces. The VNFM shall base the interactions with the VIM on a combination of: a) information in the VNF Descriptor (VNFD), which is in the form of a Topology and Orchestration Specification for Cloud Applications (TOSCA) Service Template that is delivered together with the software for the VNF, andb) deployment specific information, e.g. IP addresses, network identifiers, etc., provided by NFV Orchestrator (NFV-O) on a per deployment and per IFA007/SOL003 defined lifecycle-management operation, e.g. instantiate, scale, health check, terminate, etc., via the Or-Vnfm reference point, to the VNFM. In more detail, the VNFD describes the VNF supported lifecycle-management operations requirements on networking environment, type of resources to be orchestrated as part of a VNF instance, deployment options with regards to resources, etc., while the instance specific information details this with instance specific data. An Application Programming Interface (API) between NFV-O and VNFM is specified in "ETSI GS NFV-SOL003" and referred to as Or-Vnfm. While the SOL003 specifies the VNF related management operations needed to be supported by the VNFM, IFA010 complements this with functional requirements for the VNFM. One can from these specs derive some basic behavioral requirements that a VNFM shall fulfill when receiving a VNF lifecycle management request like "instantiate VNF of a particular type", scale an existing VNF instance, etc.: 1. Request NFVO to grant resource updates If the VNFM received request for creating a new VNF instance, or adding, changing or removing a virtual resource from an existing VNF instance, then the VNFM shall use the VNFD and the deployment flavor and instantiation level information in the request to calculate the resource changes it will do, and send a Grant request to NFVO listing this.2. Request the VIM to perform the requested management task If grant is successful, or no grant was needed, and the request is for some changes to a VNF virtualization infrastructure like a new VM image, then the VNFM shall generate the interactions towards the VIM to perform the requested task.3. Notifying NFVO of resource information for a VNF If the request type so specifies then interrogate the VIM on what resources are in existence for the VNF instance, and send this information to the NFVO, using the resource ID's defined in the VNFD to identify the different resource types. In document US 2018/316559 A1, examples are disclosed including a method of managing virtual network functions of a network functions virtualization (NFV) network environment includes generating an integration virtual network function (integration VNF) to allow a user to perform tasks related to integration and deployment of a first virtual network function (first VNF), and generating an orchestration template for a first virtual network function (first VNF) with an NFV orchestrator of the NFV environment. The method further includes reviewing the orchestration template with the integration VNF, and orchestrating deployment of the first VNF with a virtual infrastructure manager (VIM) of the NFV environment based on the orchestration template.