FORM 2
THE PATENTS ACT, 1970
(39 OF 1970)
&
THE PATENT RULES, 2003
COMPLETE SPECIFICATION
(See section 10 and rule 13)
“METHOD AND SYSTEM FOR MANAGING ONE OR MORE
CONTAINER NETWORK FUNCTION (CNF) NODES”
We, Jio Platforms Limited, an Indian National, of Office - 101, Saffron, Nr.
Centre Point, Panchwati 5 Rasta, Ambawadi, Ahmedabad - 380006, Gujarat,
India.
The following specification particularly describes the invention and the manner in
which it is to be performed.
2
METHOD AND SYSTEM FOR MANAGING ONE OR MORE
CONTAINER NETWORK FUNCTION (CNF) NODES
FIELD OF INVENTION
5
[0001] Embodiments of the present disclosure generally relate to the field of
wireless communication system. More particularly, embodiments of the present
disclosure relate to a method and a system for managing one or more container
network function (CNF) nodes.
10
BACKGROUND
[0002] The following description of related art is intended to provide background
information pertaining to the field of the disclosure. This section may include
15 certain aspects of the art that may be related to various features of the present
disclosure. However, it should be appreciated that this section be used only to
enhance the understanding of the reader with respect to the present disclosure, and
not as admissions of prior art.
20 [0003] In communication networks such as 5G communication networks, different
microservices perform different services, jobs, and tasks in the network. Different
microservices have to perform their jobs in such a way based on operational
parameters and policies, that it does not affect microservices’ own operation and
service network operations. Containerized Network Function (CNF) and
25 Containerized Network Function Component (CNFC) microservices manage how
and where the functions run across clusters in the environment, which helps to
perform service operations in the network. However, the current traditional
methods are not efficient for, such as managing the CNF/CNFC instantiations,
scaling, termination, re-instantiation of specific CNFC from a CNF in one of the
30 deployment plans, addition of new CNFC, maintaining resources and infrastructure
3
requirements, CNFC instantiation order with efficient resource utilization in the
network.
[0004] Thus, there exists an imperative need in the art to provide an efficient system
and method f 5 or managing one or more container network function (CNF) nodes.
SUMMARY
[0005] This section is provided to introduce certain aspects of the present disclosure
10 in a simplified form that are further described below in the detailed description.
This summary is not intended to identify the key features or the scope of the claimed
subject matter.
[0006] An aspect of the present disclosure may relate to a method for managing
15 one or more container network function (CNF) nodes. The method includes
receiving, by a processing unit, a containerized network function component
(CNFC) instantiation request at a container network function life cycle manager
(CNF-LM) with an input associated with a deployment plan via a user interface.
Next, the method includes sending, by the processing unit, a resource reserving
20 request to a policy execution engine (PEEGN) from the CNF-LM based on the
received CNFC instantiation request. Next, the method includes receiving, by the
processing unit, a response at the CNF-LM from the PEEGN for a successful
reservation request. Next, the method includes sending, by the processing unit, the
CNFC instantiation request to a Docker Service Adapter (DSA) from the CNF-LM
25 for instantiation of the one or more CNFC(s). Next, the method includes initiating,
by the processing unit, at a Docker host via the DSA, the instantiation of one or
more CNFC(s) of CNF based on the CNFC instantiation request and the input
associated with the deployment plan. Thereafter, the method includes receiving, by
the processing unit, an instantiation status from the Docker host at the CNFLM
30 related to the instantiation of the one or more CNFC(s) of the CNF.
4
[0007] In an exemplary aspect of the present disclosure, the CNFC instantiation
request comprises a number of instantiated CNFs, a number of CNFs in a pending
state along with a table containing CNF name, CNF version, a number of CNFCs,
CNFC version, vendor name, status, and timestamp.
5
[0008] In an exemplary aspect of the present disclosure, the input associated with
the deployment plan includes CNFC names with different version numbers,
regional sites, pod names, instantiation orders, CNFC resource constraints, and
policy.
10
[0009] In an exemplary aspect of the present disclosure, the method further
comprises storing the instantiation status, CNF details, CNFC details, deployment
plan status, host name, and container ID in the storage unit of a PVIM.
15 [0010] In an exemplary aspect of the present disclosure, managing the one or more
CNFs comprises: updating, modifying, instantiating, re-instantiating, and
terminating one or more CNFCs from one or more CNFs in the deployment plan
without terminating the functioning of the CNF, with changes in image, and
resource inputs.
20
[0011] In an exemplary aspect of the present disclosure, the method further
comprises sending an instantiation status update to a Release Management
Repository (RMR) from the CNFLM; and sending a CNF instantiation response to
the user interface for the received CNFC instantiation request upon receiving a
25 status update response from the RMR.
[0012] Another aspect of the present disclosure may relate to a system for
managing one or more container network function (CNF) nodes. The system
comprises a processing unit. The processing unit is configured to receive a CNFC
30 instantiation request at a container network function life cycle manager (CNF-LM)
5
with an input associated with a deployment plan via a user interface; send a resource
reserving request to a policy execution engine (PEEGN) via the CNFLM based on
the received CNFC instantiation request; receive a response at the CNF-LM from
the PEEGN for a successful reservation request; send the CNFC instantiation
request to a Docker Service Adapter (D 5 SA) from the CNFLM for instantiation of
the one or more CNFC(s); initiate, at a Docker host via the DSA, the instantiation
of one or more CNFC(s) of CNF based on the CNFC instantiation request and the
input associated with the deployment plan; and receive an instantiation status from
the Docker host at the CNFLM related to the instantiation of the one or more
10 CNFC(s) of the CNF.
[0013] Yet another aspect of the present disclosure may relate to a non-transitory
computer readable storage medium storing instructions for managing one or more
container network function (CNF) nodes, the instructions include executable code
15 which, when executed by one or more units of a system, causes: a processing unit
of the system to receive a CNFC instantiation request at a container network
function life cycle manager (CNF-LM) with an input associated with a deployment
plan via a user interface; send a resource reserving request to a policy execution
engine (PEEGN) via the CNFLM based on the received CNFC instantiation
20 request; receive a response at the CNF-LM from the PEEGN for a successful
reservation request; send the CNFC instantiation request to a Docker Service
Adapter (DSA) from the CNFLM for instantiation of the one or more CNFC(s);
initiate, at a Docker host via the DSA, the instantiation of one or more CNFC(s) of
CNF based on the CNFC instantiation request and the input associated with the
25 deployment plan; and receive an instantiation status from the Docker host at the
CNFLM related to the instantiation of the one or more CNFC(s) of the CNF.
6
OBJECTS OF THE INVENTION
[0014] Some of the objects of the present disclosure, which at least one
embodiment disclosed herein satisfies are listed herein below.
5
[0015] It is an object of the present disclosure to provide a system and a method for
CNF change management.
[0016] It is another object of the present disclosure to provide a system and a
10 method for handling termination and re-instantiation of specific CNFC from a CNF
in one deployment plan (site) without terminating the whole CNF with a change in
image, resource inputs, etc, and to keep the same CNFC on other deployment plans
(sites) with the older CNFC version.
15 [0017] It is yet another object of the present disclosure to provide a system and a
method for proper end-to-end execution of design or deployment or instantiation or
scaling call flow for CNF change management.
[0018] It is yet another object of the present disclosure to provide a system and a
20 method for performing prerequisites and check handling during the design,
deployment, and instantiation of a CNFC.
[0019] It is yet another object of the present disclosure to provide a system and a
method for managing resource inventory after CNFC termination and instantiation
25 required for change management.
7
DESCRIPTION OF THE DRAWINGS
[0020] The accompanying drawings, which are incorporated herein, and constitute
a part of this disclosure, illustrate exemplary embodiments of the disclosed methods
and systems in which like reference 5 numerals refer to the same parts throughout the
different drawings. Components in the drawings are not necessarily to scale,
emphasis instead being placed upon clearly illustrating the principles of the present
disclosure. Also, the embodiments shown in the figures are not to be construed as
limiting the disclosure, but the possible variants of the method and system
10 according to the disclosure are illustrated herein to highlight the advantages of the
disclosure. It will be appreciated by those skilled in the art that disclosure of such
drawings includes disclosure of electrical components or circuitry commonly used
to implement such components.
15 [0021] FIG. 1 illustrates an exemplary block diagram of a management and
orchestration (MANO) architecture.
[0022] FIG. 2 illustrates an exemplary block diagram of a computing device upon
which the features of the present disclosure may be implemented, in accordance
20 with an exemplary implementation of the present disclosure.
[0023] FIG. 3 illustrates an exemplary block diagram of a system for managing one
or more container network function (CNF) nodes, in accordance with an exemplary
implementation of the present disclosure.
25
[0024] FIG. 4 illustrates a method flow diagram for managing one or more
container network function (CNF) nodes, in accordance with an exemplary
implementation of the present disclosure.
8
[0025] FIG. 5 illustrates an exemplary process flow for CNF change management,
in accordance with exemplary implementations of the present disclosure.
[0026] FIG. 6 illustrates an exemplary process flow diagram for CNFC
instantiation, in accordance with 5 an exemplary implementation of the present
disclosure.
[0027] FIG. 7 illustrates an exemplary block diagram of a system architecture for
managing one or more container network function (CNF) nodes, in accordance with
10 an exemplary implementation of the present disclosure.
[0028] The foregoing shall be more apparent from the following more detailed
description of the disclosure.
15 DETAILED DESCRIPTION
[0029] In the following description, for the purposes of explanation, various
specific details are set forth in order to provide a thorough understanding of
embodiments of the present disclosure. It will be apparent, however, that
20 embodiments of the present disclosure may be practiced without these specific
details. Several features described hereafter may each be used independently of one
another or with any combination of other features. An individual feature may not
address any of the problems discussed above or might address only some of the
problems discussed above.
25
[0030] The ensuing description provides exemplary embodiments only, and is not
intended to limit the scope, applicability, or configuration of the disclosure. Rather,
the ensuing description of the exemplary embodiments will provide those skilled in
the art with an enabling description for implementing an exemplary embodiment.
30 It should be understood that various changes may be made in the function and
9
arrangement of elements without departing from the spirit and scope of the
disclosure as set forth.
[0031] Specific details are given in the following description to provide a thorough
understanding of the 5 embodiments. However, it will be understood by one of
ordinary skill in the art that the embodiments may be practiced without these
specific details. For example, circuits, systems, processes, and other components
may be shown as components in block diagram form in order not to obscure the
embodiments in unnecessary detail.
10
[0032] Also, it is noted that individual embodiments may be described as a process
which is depicted as a flowchart, a flow diagram, a data flow diagram, a structure
diagram, or a block diagram. Although a flowchart may describe the operations as
a sequential process, many of the operations may be performed in parallel or
15 concurrently. In addition, the order of the operations may be re-arranged. A process
is terminated when its operations are completed but could have additional steps not
included in a figure.
[0033] The word “exemplary” and/or “demonstrative” is used herein to mean
20 serving as an example, instance, or illustration. For the avoidance of doubt, the
subject matter disclosed herein is not limited by such examples. In addition, any
aspect or design described herein as “exemplary” and/or “demonstrative” is not
necessarily to be construed as preferred or advantageous over other aspects or
designs, nor is it meant to preclude equivalent exemplary structures and techniques
25 known to those of ordinary skill in the art. Furthermore, to the extent that the terms
“includes,” “has,” “contains,” and other similar words are used in either the detailed
description or the claims, such terms are intended to be inclusive—in a manner
similar to the term “comprising” as an open transition word—without precluding
any additional or other elements.
30
10
[0034] As used herein, a “processing unit” or “processor” or “operating processor”
includes one or more processors, wherein processor refers to any logic circuitry for
processing instructions. A processor may be a general-purpose processor, a special
purpose processor, a conventional processor, a digital signal processor, a plurality
of microprocessors, one or more 5 microprocessors in association with a (Digital
Signal Processing) DSP core, a controller, a microcontroller, Application Specific
Integrated Circuits, Field Programmable Gate Array circuits, any other type of
integrated circuits, etc. The processor may perform signal coding data processing,
input/output processing, and/or any other functionality that enables the working of
10 the system according to the present disclosure. More specifically, the processor or
processing unit is a hardware processor.
[0035] As used herein, “a user equipment”, “a user device”, “a smart-user-device”,
“a smart device”, “an electronic device”, “a mobile device”, “a handheld device”,
15 “a wireless communication device”, “a mobile communication device”, “a
communication device” may be any electrical, electronic and/or computing device
or equipment, capable of implementing the features of the present disclosure. The
user equipment/device may include, but is not limited to, a mobile phone, smart
phone, laptop, a general-purpose computer, desktop, personal digital assistant,
20 tablet computer, wearable device, or any other computing device that is capable of
implementing the features of the present disclosure. Also, the user device may
contain at least one input means configured to receive an input from at least one of
a transceiver unit, a processing unit, a storage unit, a detection unit, and any other
such unit(s) that are required to implement the features of the present disclosure.
25
[0036] As used herein, “storage unit” or “memory unit” refers to a machine or
computer-readable medium including any mechanism for storing information in a
form readable by a computer or similar machine. For example, a computer-readable
medium includes read-only memory (“ROM”), random access memory (“RAM”),
30 magnetic disk storage media, optical storage media, flash memory devices, or other
11
types of machine-accessible storage media. The storage unit stores at least the data
that may be required by one or more units of the system to perform their respective
functions.
[0037] As used herein “interface” or “user interface 5 refers to a shared boundary
across which two or more separate components of a system exchange information
or data. The interface may also be referred to as a set of rules or protocols that define
the communication or interaction of one or more modules or one or more units with
each other, which also includes the methods, functions, or procedures that may be
10 called.
[0038] All modules, units, and components used herein, unless explicitly excluded
herein, may be software modules or hardware processors, the processors being a
general-purpose processor, a special-purpose processor, a conventional processor,
15 a digital signal processor (DSP), a plurality of microprocessors, one or more
microprocessors in association with a DSP core, a controller, a microcontroller,
Application Specific Integrated Circuits (ASIC), Field Programmable Gate Array
circuits (FPGA), any other type of integrated circuits, etc.
20 [0039] As used herein the transceiver unit includes at least one receiver and at least
one transmitter configured respectively for receiving and transmitting data, signals,
information, or a combination thereof between units/components within the system
and/or connected with the system.
25 [0040] As used herein, the Physical and Virtual Inventory Manager (PVIM) module
maintains the inventory and its resources. After getting a request to reserve
resources from PEEGN, PVIM adds up the resources consumed by a particular
network function as used resources. Further, the PVIM updates this in the NoSQL
database.
30
12
[0041] As used herein, Containerized Network Function (CNF) Life Cycle
Manager (CNF-LM/ CNFLM) may capture the details of vendors, CNFs, and
Containerized Network Function Components (CNFCs) via create, read, and update
APIs exposed by the service itself. The captured details are stored in a database.
CNFLM may create CNF or individual CNFC 5 instances. CNF-LM may scale out
the CNFs.
[0042] As used herein, Policy Execution Engine (PEEGN) module provides a
network function virtualisation (NFV) software-defined network (SDN) platform
10 functionality to support dynamic requirements of resource management and
network service orchestration in the virtualized network. Further, the PEEGN is
involved during the CNF instantiation flow to check for CNF policy and to reserve
the resources required to instantiate CNF at PVIM. PEEGN supports the scaling
policy for CNFC.
15
[0043] As used herein, the Docker Service Adapter (DSA) may be used to establish
CNF instances / CNFC instances. DSA may connect to the docker host of the swarm
manager to deploy the docker image. In a call flow, DSA may create a docker
service manager and add a docker host as a service worker node. DSA may be
20 deployed region-wise, and all containerized network function-related operations
may be performed region-wise. DSA is a microservices-based system designed to
deploy and manage Container Network Functions (CNFs) and their components
(CNFCs) across Docker nodes. It offers REST endpoints for key operations,
including uploading container images to a Docker registry, terminating CNFC
25 instances, and creating Docker volumes and networks. CNFs, which are network
functions packaged as containers, may consist of multiple CNFCs. The DSA
facilitates the deployment, configuration, and management of these components by
interacting with Docker's API, ensuring proper setup and scalability within a
containerized environment. This approach provides a modular and flexible
30 framework for handling network functions in a virtualized network setup.
13
[0044] As discussed in the background section, the current known solutions have
several shortcomings. The present disclosure aims to overcome the abovementioned
and other existing problems in this field of technology by providing a
method and system for 5 managing one or more container network function (CNF)
nodes.
[0045] The present method and system provide a solution, that handle termination
and re-instantiation of specific CNFC from a CNF in one deployment plan (site)
10 without terminating the whole CNF with a change in image, resource inputs etc.
The present disclosure enables a solution for keeping the same CNFC on other
deployment plans (sites) on the older CNFC version. The present method and
system provide a solution, that supports the addition of a new CNFC to an existing
running CNF and managing data of an existing running CNF while adding a new
15 CNFC or new version of an existing CNFC. The present method and system provide
a solution, which maintains CNF/CNFC resources and infrastructure as per
requirements. The present method and system provide a solution, that enables
modification of an existing CNFC in a CNF, such as image update or any virtual
resource modification, if the user fully terminates the CNFC to be modified on all
20 the sites. The present method and system provide a solution, which handles
prerequisites and checks applicable for CNF change management and CNFC antiaffinity
or affinity policy, if applicable. The present method and system maintain
method and procedure for CNFC instantiation order. The present method and
system provide a solution, that supports highly available modes for all events with
25 cache-less operation, so no data replication is required. The present method and
system provide async event-based implementation to utilize the supported interface
efficiently. The present method and system implement Extended Detection and
Response (XDR) for all operations.
14
[0046] The present disclosure is implemented in networks such as, but not limited
to 5G networks, network preceding 5G (e.g., 4G network), and networks post 5G
(e.g., 6G network).
[0047] The foregoing shall be 5 more apparent from the following more detailed
description of the disclosure.
[0048] Hereinafter, exemplary embodiments of the present disclosure will be
described with reference to the accompanying drawings.
10
[0049] FIG. 1 illustrates an exemplary block diagram representation of a
management and orchestration (MANO) architecture/ platform [100], in
accordance with exemplary implementation of the present disclosure. The MANO
architecture [100] may be developed for managing telecom cloud infrastructure
15 automatically, managing design or deployment design, managing instantiation of
network node(s)/ service(s) etc. The MANO architecture [100] deploys the network
node(s) in the form of a Virtual Network Function (VNF) and Cloud-native/
Container Network Function (CNF). The system as provided by the present
disclosure may comprise one or more components of the MANO architecture [100].
20 The MANO architecture [100] may be used to auto-instantiate the VNFs into the
corresponding environment of the present disclosure so that it could help in
onboarding other vendor(s) CNFs and VNFs to the platform.
[0050] As shown in FIG. 1, the MANO architecture [100] comprises a user
25 interface layer [102], a network function virtualization (NFV) and software-defined
network (SDN) design function module [104], a platform foundation services
module [106], a Platform Schedulers & Cron Jobs module [108] and a platform
resource adapters and utilities module [112]. All the components are assumed to be
connected to each other in a manner as obvious to the person skilled in the art of
30 implementing features of the present disclosure.
15
[0051] The NFV and SDN design function module [104] comprises a VNF
lifecycle manager (compute) [1042], a VNF catalog [1044], a network services
catalog [1046], a network slicing and service chaining manager [1048], a physical
and virtual resource manager [1050] and a CNF 5 lifecycle manager [1052]. The VNF
lifecycle manager (compute) [1042] may be responsible for deciding on which
server of the communication network, the microservice will be instantiated. The
VNF lifecycle manager (compute) [1042] may manage the overall flow of
incoming/ outgoing requests during interaction with the user. The VNF lifecycle
10 manager (compute) [1042] may be responsible for determining which sequence to
be followed for executing the process. For e.g., in an AMF network function of the
communication network (such as a 5G network), a sequence for execution of
processes P1 and P2 etc. The VNF catalog [1044] stores the metadata of all the
VNFs (also CNFs in some cases). The network services catalog [1046] stores the
15 information on the services that need to be run. The network slicing and service
chaining manager [1048] manages the slicing (an ordered and connected sequence
of network service/ network functions (NFs)) that must be applied to a specific
networked data packet. The physical and virtual resource manager [1050] stores the
logical and physical inventory of the VNFs. Just like the VNF lifecycle manager
20 (compute) [1042], the CNF lifecycle manager [1052] may be used for the CNFs
lifecycle management.
[0052] The platform foundation services module [106] comprises a microservices
elastic load balancer [1062], an identity & access manager [1064], a command line
25 interface (CLI) [1066], a central logging manager [1068], and an event routing
manager [1070]. The microservices elastic load balancer [1062] may be used for
maintaining the load balancing of the request for the services. The identity & access
manager [1064] may be used for logging purposes. The command line interface
(CLI) [1066] may be used to provide commands to execute certain processes which
16
require changes during the run time. The central logging manager [1068] may be
responsible for keeping the logs of every service. These logs are generated by the
MANO platform [100]. These logs are used for debugging purposes. The event
routing manager [1070] may be responsible for routing the events i.e., the
application programming interface 5 (API) hits to the corresponding services.
[0053] The platforms core services module [108] comprises an NFV infrastructure
monitoring manager [1082], an assure manager [1084], a performance manager
[1086], a policy execution engine [1088], a capacity monitoring manager [1090], a
10 release management (mgmt.) repository [1092], a configuration manager & GCT
[1094], an NFV platform decision analytics [1096], a platform NoSQL DB [1098];
a platform schedulers and cron jobs [1100], a VNF backup & upgrade manager
[1102], a microservice auditor [1104], and a platform operations, administration
and maintenance manager [1106]. The NFV infrastructure monitoring manager
15 [1082] monitors the infrastructure part of the NFs. For e.g., any metrics such as
CPU utilization by the VNF. The assure manager [1084] may be responsible for
supervising the alarms the vendor may be generating. The performance manager
[1086] may be responsible for managing the performance counters. The policy
execution engine (PEGN) [1088] may be responsible for managing all of the
20 policies. The capacity monitoring manager (CMM) [1090] may be responsible for
sending the request to the PEGN [1090]. The release management (mgmt.)
repository (RMR) [1092] may be responsible for managing the releases and the
images of all of the vendor's network nodes. The configuration manager & (GCT)
[1094] manages the configuration and GCT of all the vendors. The NFV platform
25 decision analytics (NPDA) [1096] helps in deciding the priority of using the
network resources. It may be further noted that the policy execution engine (PEGN)
[1088], the configuration manager & GCT [1094], and the NPDA [1096] work
together. The platform NoSQL DB [1098] may be a database for storing all the
inventory (both physical and logical) as well as the metadata of the VNFs and CNF.
30 The platform schedulers and cron jobs [1100] schedule the tasks such as but not
17
limited to triggering an event, traversing the network graph etc. The VNF backup
& upgrade manager [1102] takes backup of the images, and binaries of the VNFs
and the CNFs and produces those backups on demand in case of server failure. The
microservice auditor [1104] audits the microservices. E.g., in a hypothetical case,
instances not being instantiated 5 by the MANO architecture [100] may be using the
network resources. In such cases, the microservice auditor [1104] audits and
informs the same so that resources can be released for services running in the
MANO architecture [100]. The audit assures that the services only run on the
MANO platform [100]. The platform operations, administration, and maintenance
10 manager [1106] may be used for newer instances that are spawning.
[0054] The platform resource adapters and utilities module [112] further comprises
a platform external API adaptor and gateway [1122]; a generic decoder and indexer
(XML, CSV, JSON) [1124]; a docker service adaptor [1126]; an API adapter
15 [1128]; and a NFV gateway [1130]. The platform's external API adaptor and
gateway [1122] may be responsible for handling the external services (to the
MANO platform [100]) that require the network resources. The generic decoder
and indexer (XML, CSV, JSON) [1124] gets directly the data of the vendor system
in the XML, CSV, and JSON format. The docker service adaptor [1126] may be the
20 interface provided between the telecom cloud and the MANO architecture [100] for
communication. The OpenStack API adapter [1128] may be used to connect with
the virtual machines (VMs). The NFV gateway [1130] may be responsible for
providing the path to each service going to/incoming from the MANO architecture
[100].
25
[0055] Referring to FIG. 2, an exemplary block diagram of a computing device
[200] (also referred to herein as a computer system [200]) upon which the features
of the present disclosure may be implemented in accordance with exemplary
implementation of the present disclosure, is shown. In an implementation, the
30 computing device [200] may also implement a method for managing one or more
18
container network function (CNF) nodes utilizing the system. In another
implementation, the computing device [200] itself implements the method for
managing one or more container network function (CNF) nodes using one or more
units configured within the computing device [200], wherein said one or more units
are capable of implementing the 5 features as disclosed in the present disclosure.
[0056] The computing device [200] may include a bus [202] or other
communication mechanism for communicating information, and a hardware
processor [204] coupled with the bus [202] for processing information. The
10 hardware processor [204] may be, for example, a general-purpose microprocessor.
The computing device [200] may also include a main memory [206], such as a
random-access memory (RAM), or other dynamic storage device, coupled to the
bus [202] for storing information and instructions to be executed by the processor
[204]. The main memory [206] also may be used for storing temporary variables or
15 other intermediate information during the execution of the instructions to be
executed by the processor [204]. Such instructions, when stored in non-transitory
storage media accessible to the processor [204], render the computing device [200]
into a special-purpose machine that is customized to perform the operations
specified in the instructions. The computing device [200] further includes a read
20 only memory (ROM) [208] or other static storage device coupled to the bus [202]
for storing static information and instructions for the processor [204].
[0057] A storage device [210], such as a magnetic disk, optical disk, or solid-state
drive is provided and coupled to the bus [202] for storing information and
25 instructions. The computing device [200] may be coupled via the bus [202] to a
display [212], such as a cathode ray tube (CRT), Liquid crystal Display (LCD),
Light Emitting Diode (LED) display, Organic LED (OLED) display, etc. for
displaying information to a computer user. An input device [214], including
alphanumeric and other keys, touch screen input means, etc. may be coupled to the
30 bus [202] for communicating information and command selections to the processor
19
[204]. Another type of user input device may be a cursor controller [216], such as
a mouse, a trackball, or cursor direction keys, for communicating direction
information and command selections to the processor [204], and for controlling
cursor movement on the display [212]. The input device typically has two degrees
of freedom in two axes, a first axis (e.g., x) 5 and a second axis (e.g., y), that allow
the device to specify positions in a plane.
[0058] The computing device [200] may implement the techniques described
herein using customized hard-wired logic, one or more ASICs or FPGAs, firmware,
10 and/or program logic which in combination with the computing device [200] causes
or programs the computing device [200] to be a special-purpose machine.
According to one implementation, the techniques herein are performed by the
computing device [200] in response to the processor [204] executing one or more
sequences of one or more instructions contained in the main memory [206]. Such
15 instructions may be read into the main memory [206] from another storage medium,
such as the storage device [210]. Execution of the sequences of instructions
contained in the main memory [206] causes the processor [204] to perform the
process steps described herein. In alternative implementations of the present
disclosure, hard-wired circuitry may be used in place of or in combination with
20 software instructions.
[0059] The computing device [200] also may include a communication interface
[218] coupled to the bus [202]. The communication interface [218] provides a twoway
data communication coupling to a network link [220] that is connected to a
25 local network [222]. For example, the communication interface [218] may be an
integrated services digital network (ISDN) card, cable modem, satellite modem, or
a modem to provide a data communication connection to a corresponding type of
telephone line. As another example, the communication interface [218] may be a
local area network (LAN) card to provide a data communication connection to a
30 compatible LAN. Wireless links may also be implemented. In any such
20
implementation, the communication interface [218] sends and receives electrical,
electromagnetic or optical signals that carry digital data streams representing
various types of information.
[0060] The computing device [200] can 5 send messages and receive data, including
program code, through the network(s), the network link [220] and the
communication interface [218]. In the Internet example, a server [230] might
transmit a requested code for an application program through the Internet [228], the
ISP [226], the local network [222], the host [224] and the communication interface
10 [218]. The received code may be executed by the processor [204] as it is received,
and/or stored in the storage device [210], or other non-volatile storage for later
execution.
[0061] Referring to FIG. 3, an exemplary block diagram of a system [300]
15 managing one or more container network function (CNF) nodes is shown, in
accordance with the exemplary implementations of the present disclosure. The
system [300] comprises at least one processing unit [302] and at least one storing
unit [304]. Also, all of the components/ units of the system [300] are assumed to be
connected to each other unless otherwise indicated below. Also, in FIG. 3 only a
20 few units are shown, however, the system [300] may comprise multiple such units
or the system [300] may comprise any such numbers of said units, as required to
implement the features of the present disclosure. In an implementation, the system
[300] may reside in a server or a network entity. In yet another implementation, the
system [300] may reside partly in the server/ network entity.
25
[0062] The system [300] is configured for managing one or more container network
function (CNF) nodes, with the help of the interconnection between the
components/units of the system [300].
21
[0063] The system [300] comprises a processing unit [302]. The processing unit
[302] is configured to receive a CNFC instantiation request at a container network
function life cycle manager (CNF-LM) with an input associated with a deployment
plan via a user interface. In an operation for managing one or more CNF nodes, the
processing unit [302] is configured to receive 5 the CNFC request at CNF-LM with
an input via the user interface (e.g., interface associated with mobile device,
computing device, human machine interface (HMI)). The CNFC instantiation
request may comprise such as, but not limited to, a number of instantiated CNFs, a
number of CNFs in a pending state along with a table containing CNF name, CNF
10 version, a number of CNFCs, CNFC version, vendor name, status (e.g., pending or
completed), and timestamp. In an exemplary implementation, a user such as, but
not limited to, a network administrator, a service provider, and an authorised person
may provide the input via the user interface with the deployment plan. The input
associated with the deployment plan may comprise such as, but not limited to,
15 CNFC names with different version numbers, regional sites, pod names,
instantiation order, CNFC resource constraints, and policy. In an exemplary
implementation, the CNFC resource constraints may include such as compute,
CPU, storage, RAM, Disk, network, image, or virtual resources. In an exemplary
implementation, policy may be such as affinity or anti-affinity. In an exemplary
20 implementation, management of one or more CNFs corresponds to updating,
modifying, instantiating, re-instantiating, and terminating one or more CNFCs from
one or more CNFs in the deployment plan without terminating the functioning of
the CNF, with changes in image, and resource inputs. The processing unit [302] is
configured to store input associated with deployment in a storage unit [304].
25
[0064] The processing unit [302] is configured to send a resource reserving request
to a policy execution engine (PEEGN) via the CNFLM based on the received CNFC
instantiation request. After receiving the CNFC instantiation request with input
associated with the deployment plan, the processing unit [302] is configured to send
30 the resource reserving request to the PEEGN via the CNFLM. In an exemplary
implementation, the processing unit [302] is configured to perform via the PEEGN
22
a quota check based on the stored details and deployment plan for the CNF/CNFC.
The quota check may be associated with such as, but not limited to, CPU, memory,
and disk so that resource constraints do not fail during instantiation.
[0065] The processing unit [302] is further configured 5 to receive a response at the
CNF-LM from the PEEGN for a successful reservation request. In response to this
request, the processing unit [302] is configured to receive the response from the
PEEGN for a successful reservation request, such as a reservation acknowledgment.
In an example, the response may comprise such as details associated with reserved
10 resources, such as CPU and memory.
[0066] The processing unit [302] is configured to send the CNFC instantiation
request to a Docker Service Adapter (DSA) from the CNFLM for instantiation of
the one or more CNFC(s). After receiving the successful response from the PEEGN,
15 the processing unit [302] is configured to send the CNFC instantiation request to
the DSA for instantiation of the one or more CNFC(s). Further, the CNFC
instantiation request may comprise the input associated with the deployment plan.
The processing unit [302] is configured to send via the CNF-LM such as but not
limited to, CNF version, the number of CNFCs, CNFC version, and vendor name
20 to the DSA for instantiation of the one or more CNFC(s).
[0067] The processing unit [302] is configured to initiate, at a Docker host via the
DSA, the instantiation of one or more CNFC(s) of CNF based on the CNFC
instantiation request and the input associated with the deployment plan. After
25 receiving the CNFC instantiation request, the processing unit [302] is configured to
initiate at the Docker host the instantiation of one or more CNFC(s) via the DSA.
In an exemplary implementation, DSA may communicate with the docker agent
manager. The docker agent manager may communicate with the service manager
having one or more DSA host(s) and initiate the instantiation of one or more
30 CNFC(s) of CNF based on the CNFC instantiation request and the input associated
with the deployment plan.
23
[0068] The processing unit [302] is configured to receive an instantiation status
from the Docker host at the CNF-LM related to the instantiation of the one or more
CNFC(s) of the CNF. After performing the instantiation of one or more CNFCs
based on the deployment 5 plan, the processing unit [302] is configured to receive at
the CNFLM the instantiation status of the one or more CNFC(s) of the CNF from
the Docker host. In an exemplary implementation, the Docker host may
communicate the instantiation status with the DSA. The DSA may send the
instantiation status to the CNF-LM. In an implementation, the instantiation status
10 may comprise at least one from among an acknowledgment and status (e.g., pending
or complete). After receiving the instantiation status, the processing unit is further
configured to store the instantiation status, CNF details, CNFC details, deployment
plan status (e.g., successful, partially completed, or not completed), host name,
container ID in the storage unit [304] of a Physical Virtual Inventory Manager
15 (PVIM).
[0069] In an exemplary implementation, the processing unit [302] is configured to
send an instantiation status update to a Release Management Repository (RMR)
from the CNFLM. The CNFLM may send the instantiation status such as pending
20 or complete to the RMR for storing and further processing in the network. In
response to this, RMR may send a status update response such as an
acknowledgement to CNFLM. The processing unit [302] is further configured to
send via the CNFLM a CNF instantiation response to the user interface for the
received CNFC instantiation request upon receiving the status update response from
25 the RMR.
[0070] Further, in accordance with the present disclosure, it is to be acknowledged
that the functionality described for the various components/units can be
implemented interchangeably. While specific embodiments may disclose a
30 particular functionality of these units for clarity, it is recognized that various
configurations and combinations thereof are within the scope of the disclosure. The
24
functionality of specific units as disclosed in the disclosure should not be construed
as limiting the scope of the present disclosure. Consequently, alternative
arrangements and substitutions of units, provided they achieve the intended
functionality described herein, are considered to be encompassed within the scope
5 of the present disclosure.
[0071] Referring to FIG. 4 an exemplary method flow diagram [400], to perform
resource management for Virtual Network Function (VNF) / VNFC instantiation,
in accordance with exemplary implementations of the present disclosure is shown.
10 In an implementation, the method [400] is performed by the system [300]. As
shown in FIG. 4, the method [400] starts at step [402].
[0072] At step [404], the method [400] as disclosed by the present disclosure
comprises receiving, by a processing unit [302], a containerized network function
15 component (CNFC) instantiation request at a container network function life cycle
manager (CNF-LM) with an input associated with a deployment plan via a user
interface. In an operation for managing one or more CNF nodes, the processing unit
[302] may receive the CNFC request at CNF-LM with an input via the user interface
(e.g., interface associated with mobile device, computing device, human machine
20 interface (HMI)). The CNFC instantiation request may comprise such as, but not
limited to, a number of instantiated CNFs, a number of CNFs in a pending state
along with a table containing CNF name, CNF version, a number of CNFCs, CNFC
version, vendor name, status (e.g., pending or completed), and timestamp. In an
exemplary implementation, a user such as, but not limited to, a network
25 administrator, a service provider, and an authorized person may provide the input
via the user interface with the deployment plan. The input associated with the
deployment plan may comprise such as, but not limited to, CNFC names with
different version numbers, regional sites, pod names, instantiation order, CNFC
resource constraints, and policy. In an exemplary implementation, the CNFC
30 resource constraints may be such as compute, CPU, storage, RAM, Disk, network,
image, or virtual resources. In an exemplary implementation, policy may be such
25
as affinity or anti-affinity. In an exemplary implementation, management of the one
or more CNFs corresponds to updating, modifying, instantiating, re-instantiating,
and terminating one or more CNFCs from one or more CNFs in the deployment
plan without terminating the functioning of the CNF, with changes in image, and
resource inputs. The processing 5 unit [302] may store input associated with
deployment in a storage unit [304].
[0073] Next at step [406], the method [400], as disclosed by the present disclosure,
comprises sending, by the processing unit [302], a resource reserving request to a
10 policy execution engine (PEEGN) from the CNF-LM based on the received CNFC
instantiation request. After receiving the CNFC instantiation request with input
associated with the deployment plan, the processing unit [302] may send the
resource reserving request to the PEEGN via the CNFLM. In an exemplary
implementation, the processing unit [302] may perform via the PEEGN a quota
15 check based on the stored details and deployment plan for the CNF/CNFC. The
quota check may be associated with such as, but not limited to, CPU, memory, and
disk so that resource constraints do not fail during instantiation.
[0074] Next at step [408], the method [400] as disclosed by the present disclosure
20 comprises receiving, by the processing unit [302], a response at the CNF-LM from
the PEEGN for a successful reservation request. In response to this request, the
processing unit [302] may receive the response from the PEEGN for a successful
reservation request, such as a reservation acknowledgment. In an example, the
response may comprise such as details associated with reserved resources, such as
25 CPU and memory.
[0075] Next at step [410], the method [400] as disclosed by the present disclosure
comprises sending, by the processing unit [302], the CNFC instantiation request to
a Docker Service Adapter (DSA) from the CNF-LM for instantiation of the one or
30 more CNFC(s). After receiving the successful response from the PEEGN, the
26
processing unit [302] may send the CNFC instantiation request to the DSA for
instantiation of the one or more CNFC(s). Further, the CNFC instantiation request
may comprise the input associated with the deployment plan. The processing unit
[302] may send, via the CNF-LM, such as but not limited to, CNF version, the
number of CNFCs, CNFC version, and 5 vendor name to the DSA for instantiation
of the one or more CNFC(s).
[0076] Next at step [412], the method [400], as disclosed by the present disclosure,
comprises initiating, by the processing unit [302], at a Docker host via the DSA, the
10 instantiation of one or more CNFC(s) of CNF based on the CNFC instantiation
request and the input associated with the deployment plan. After receiving the
CNFC instantiation request, the processing unit [302] may initiate at the Docker
host the instantiation of one or more CNFC(s) via the DSA. In an exemplary
implementation, DSA may communicate with the docker agent manager. The
15 docker agent manager further may communicate with service manager having one
or more DSA host(s) and initiate the instantiation of one or more CNFC(s) of CNF
based on the CNFC instantiation request and the input associated with the
deployment plan.
20 [0077] Next at step [414], the method [400] as disclosed by the present disclosure
comprises receiving, by the processing unit [302], an instantiation status from the
Docker host at the CNFLM related to the instantiation of the one or more CNFC(s)
of the CNF. After performing the instantiation of one or more CNFCs based on the
deployment plan, the processing unit [302] may receive at the CNFLM the
25 instantiation status of the one or more CNFC(s) of the CNF from the Docker host.
In an exemplary implementation, the Docker host may communicate the
instantiation status with the DSA. The DSA may send the instantiation status to the
CNF-LM. In an implementation, the instantiation status may comprise at least one
from an acknowledgment and status (e.g., pending or complete). After receiving the
30 instantiation status, the processing unit may further store the instantiation status,
CNF details, CNFC details, deployment plan status (e.g., successful, partially
27
completed, or not completed), host name, container ID in the storage unit [304] of
a Physical Virtual Inventory Manager (PVIM).
[0078] In an exemplary implementation, the processing unit [302] may send an
instantiation status update to a Release 5 Management Repository (RMR) from the
CNFLM. The CNFLM may send the instantiation status such as pending or
complete to the RMR for storing and further processing in the network. In response
to this, RMR may send a status update response such as an acknowledgement to
CNFLM. The processing unit [302] may further send via the CNFLM a CNF
10 instantiation response to the user interface for the received CNFC instantiation
request upon receiving the status update response from the RMR.
[0079] Thereafter, the method [400] terminates at step [416].
15 [0080] Referring to FIG. 5, an exemplary process flow [500] for CNF change
management, in accordance with exemplary implementations of the present
disclosure, is shown. As shown in FIG. 5, the process flow [500] involves or
comprises a user [502], a UI/UX [504], a Release Management Repository (RMR)
[1092], and a CNF Lifecycle Manager (CNFLM) [1052]. The CNF change
20 management design operation may perform, but is not limited to, to following steps:
- At step S1, user [502] may request CNF change management by providing input
such as vendor name and CNF name to UI/UX [504].
25 - At step S2, UI/UX [504] sends a request for getting CNF change data to the
RMR [1092].
- Next, at step S3, in response to this, the RMR [1092] provides acknowledgment
for CNF change data.
30
28
- At step S4, user [502] may select the CNF edit option, which may be present in
a drop-down or tabular form to UI/UX [504].
- At step S5, UI/UX [504] sends a request for getting CNF data along with
5 CNFCs to the CNFLM [1052].
- At step S6, CNFLM [1052] provides acknowledgement for CNF data along
with CNFCs.
10 - At step S7, user [502] updates CNFC design parameters, such as, but not limited
to, compute, Network, Storage, Image, etc. to the UI/UX [504].
- At step S8, UI/UX [502] saves the CNF detail draft or plan into the RMR
[1092].
15
- Next, at step S9, in response to this, RMR [1092] provides acknowledgment for
saving the CNF detail draft or plan to the UI/UX [504].
- At step S10, UI/UX [504] saves CNF data along with CNFCs to the CNFLM
20 [1052].
- Next, at step S11, CNFLM [1052] provides acknowledgment for saving CNF
status details to the UI/UX [504].
25 - At step S12, UI/UX [504] provides CNF status to the user [502].
[0081] In an exemplary implementation, a user may first select change management
from the CNF maintenance option available on UI and then select the “Vendor
Name” and “CNF Name”. Only those entries are shown to the user which are
30 successfully instantiated. Further change-related information (CNF Version,
Change Status, Timestamp, and available action options) may be shown to the user
in a tabular form. From action options, the user may click on the “Edit” button, to
design a CNFC using the existing CNFC as a new version or create a new CNFC
29
under CNF. While modifying existing CNFC, the old CNFC data is prepopulated
automatically allowing the user to make changes in any resource requirements
(Compute, Storage, Network, etc) as per requirement. If the existing CNFC is part
of the anti-affinity or affinity policy, then the user may edit policies for modified
CNFC. There may be a validation check at the anti-5 affinity or affinity policy section
to avoid the selection of both the CNFC versions (Modified and Existing) at a time.
[0082] In an exemplary implementation, for CNF change management call flow,
UI is hosted on a UI container, and it has access to all interfaces and components.
10 Next, a Centralized Platform Operations, Administration, and Maintenance
Manager (POAM) may be run in the environment, and it has the visibility of the
complete environment and microservices. Next, all microservices (CNFLM, PVIM,
PEEGN, DSA, etc.) may connect with POAM. Next, the POAM may provide
available microservice instance and Load balancer details back to microservices in
15 the form of broadcast data. This broadcast data has all the required details that is
consumed by microservices. Once this information is set at microservices, they are
ready for work and accept requests. Further, the user may initiate a change
management request from the UI and start the design, deployment, or instantiation
flow.
20
[0083] In an exemplary implementation, for CNF Change Management
Deployment, the present method and system may perform, but not limited to, the
following steps: Once the design changes are done for the CNF, the user may create
or modify the existing deployment plan. Next, in the deployment phase, the user
25 may select the CNFC Names of each CNFC. For example, there are three CNFCs
with the names CNFC1v1, CNFC1v2, and CNFC2v1. The user may select from the
dropdown in case there are multiple entries of the same CNFC Names with different
versions. Next, the user may select sites, pod names, instantiation orders, and CNFC
resource constraints (CPU, RAM, Disk). Next, the user selects affinity/anti affinity
30 option for CNFC. If affinity is defined between CNFCs and the user-selected “site”,
30
then all the CNFCs with affinity policy may get the name site selected
automatically. Next, on saving the deployment plan, an entry may be created that
can be instantiated by the user.
[0084] Referring to FIG. 6, an exemplary 5 process flow diagram [600] for CNFC
instantiation, in accordance with the exemplary implementations of the present
disclosure, is shown. As shown in FIG. 6, the process flow [600] comprises a user
[502], a UI/UX [504], a CNF Lifecycle Manager (CNFLM) [1052], a Policy
Execution Engine (PEEGN) [1088], a Physical & Virtual Inventory Manager
10 (PVIM) (also referred as Physical & Virtual Resource Manager) [1050], a Docker
Service Adaptor (DSA) [1126], a Docker Host [602] and a Release Management
Repository (RMR) [1092]. The process flow [500] has the following steps for
CNFC instantiation:
15 - At step S1, user [502] may request for CNFC instantiation to UI/UX [504].
- At step S2, UI/UX [504] may send a request for CNFC instantiation to the
CNFLM [1052].
20 - At step S3, CNFLM [1052] may send the request for reserving resources and
fetching region details, to the PEEGN [1088].
- At step S4, the PEEGN [1088] may send resources reserving acknowledgment
to the CNFLM [1052].
25
- At step S5, CNFLM [1052] sends a CNFC instantiation request to DSA [1126].
- At step S6, DSA [1126] sends the CNFC instantiation request to the Docker
host [602].
30
- Next, at step S7, in response to this, Docker host [602] sends instantiation status,
such as, but not limited to, complete, partial complete to the DSA [1126].
31
- Next, at step S8, the DSA sends instantiation the acknowledgement to the
CNFLM [1052].
- Next, at step S9, in response to the 5 instantiation, the CNFLM [1052] sends an
update inventory request to the PVIM [1050].
- Next, at step S10, PVIM [1050] sends the update inventory acknowledgement
to the CNFLM [1052].
10
- Next, at step S11, CNFLM [1052] sends a request for an update of the
instantiation status to the RMR [1092].
- Next, at step S12, RMR [1092] sends an acknowledgment after updating the
15 instantiation status to the CNFLM [1052].
- Further, at step S13, CNFLM [1052] sends CNFC instantiation
acknowledgment to the UI/UX [504] and UI/UX [504] further sends, at step
S14, the instantiation acknowledgment to the user [502].
20
[0085] In an exemplary implementation, the CNFC Change Management
Instantiation operation may perform the following steps: CNFCs added from
change management may be instantiated by the user by selecting a deployment plan.
Next, on clicking the “Instantiation” tab from “CNF Lifecycle Management”, the
25 user may be able to see the “No of CNFs” instantiated and the “No of CNFs” in
Pending state along with a table containing the CNF name, CNF version, No of
CNFCs, Vendor name, Status (Pending/Completed) and Last updated time stamp.
Next, on clicking on an entry where instantiation is pending, the deployment plans
created in the “Deployment Planning” phase are visible to the user. Next, in case a
30 new CNFC is added to the deployment plan or a new version of an old CNFC is
updated in the deployment plan, then these CNFCs may be shown as “Deployed
Status” – “Pending”. The user can click on this CNFC and click the “Instantiate”
32
option to instantiate this CNFC. The Host Name, Container ID, and Status may be
populated after the instantiation is done. After successful instantiation, the
Deployed Status will become “Success”, the user may see all the information after
completion of instantiation of a CNFC.
5
[0086] Referring to FIG. 7, an exemplary block diagram of a system architecture
[700] for managing one or more container network function (CNF) nodes, in
accordance with an exemplary implementation of the present disclosure. As shown
in FIG. 7, the system [700] comprises at least one user interface (UI) [702], at least
10 one CNF Lifecycle Manager (CNFLM) [1052], at least one elastic search (ES)
[704], at least one Policy execution engine (PEEGN) [1088], at least one Release
management repository (RMR) [1092], at least one physical & virtual inventory
manager (PVIM) [1050], at least one DSA [1126] (DSA1 [1126a]…DSA, [1126n]).
The system [700] further comprises at least one region. The at least one region
15 comprises at least one docker agent manager (DAM) [708] and at least one swarm
manager [706] and at least one worker node (also referred to as Docker host) W
[710]/W [712].
[0087] UI [702] sends a request to the CNFLM [1052] for such as, onboarding,
20 instantiating, and terminating a CNF instance.
[0088] Next, the CNFLM [1052] captures the details of vendors, CNFs, and CNFCs
using Create, Read, and Update APIs exposed by the service itself. The captured
details are stored in a database and can be further used by the DSA service. The
25 CNFLM may be used for creation of CNF or individual CNFC instances. Further,
CNFLM [1052] may scale out CNFs or individual CNFCs as per the requirement.
[0089] Further, the PEEGN [1088] is involved during the CNF instantiation flow
to check for CNF policy and to reserve the resources required to instantiate CNF at
30 PVIM [1050]. The PEEGN [1088] supports the scaling policy for CNFC. The
PVIM [1050] may subscribe to CNFLM [1052] for any acknowledgment event to
33
get the status of instantiated CNF/CNFC and update its inventory mapping from
reserved to use.
[0090] Next, the CNFLM [1052] may interact with DSA [1126] to spawn
appropriate CNF instances / CNFC 5 instances. The DSA [1126] may directly
connect to docker host W [710]/[712] of swarm manager [706] to deploy the docker
image to docker host nodes. In the Call flow, the DSA [1126] may connect with the
Docker swarm manager [706] to add Docker hosts as swarm worker nodes (e.g.,
W1 [710a]..W1[710n] and W1 [720a]..W1[720n]). The DSA [1126] is deployed
10 region-wise (e.g., DSA1 [1126a]..DSAn [1126n]). Further, all the CNF-related
operations are also performed region-wise. The CNFLM [1052] asks region related
detail to PEEGN [1088] and based on that ELB routes such requests to regionspecific
DSAs [1052]. A swarm manager [706a-706n] may connect with multiple
Docker hosts (e.g., W [710a-710n], W [712a-712n]) which run in swarm mode and
15 act as managers (to manage membership, delegation), and workers (which run
swarm services). A given Docker host can be a manager, a worker, or perform both
roles. During the creation of a service, the system may define its optimal state, a
number of replicas, network and storage resources available to it, ports the service
exposes to the outside world, and more.
20
[0091] The present disclosure may relate to a non-transitory computer readable
storage medium storing instructions for managing one or more container network
function (CNF) nodes, the instructions include executable code which, when
executed by one or more units of a system [300], causes: a processing unit [302] of
25 the system to: receive a CNFC instantiation request at a container network function
life cycle manager (CNF-LM) with an input associated with a deployment plan via
a user interface; send a resource reserving request to a policy execution engine
(PEEGN) via the CNFLM based on the received CNFC instantiation request;
receive a response at the CNF-LM from the PEEGN for a successful reservation
30 request; send the CNFC instantiation request a to a Docker Service Adapter (DSA)
34
from the CNFLM for instantiation of the one or more CNFC(s); initiate, at the
Docker host via the DSA, the instantiation of one or more CNFC(s) of CNF based
on the CNFC instantiation request and the input associated with the deployment
plan; and receive an instantiation status from the Docker host at the CNFLM related
5 to the instantiation of the one or more CNFC(s) of the CNF.
[0092] As is evident from the above, the present disclosure provides a technically
advanced solution for an efficient system and method for managing CNF life cycle
management. The present method and system provide a solution, that handles
10 termination and re-instantiation of specific CNFC from a CNF in one deployment
plan (site) without terminating the whole CNF with a change in image, resource
inputs, etc. The present disclosure enables a solution for keeping the same CNFC
on other deployment plans (sites) with the older CNFC version. The present method
and system provide a solution, that supports the addition of a new CNFC to an
15 existing running CNF and managing data of an existing running CNF while adding
a new CNFC or new version of an existing CNFC. The present method and system
provide a solution, which maintains CNF/CNFC resources and infrastructure as per
requirements. The present method and system provide a solution, that enables
modification of an existing CNFC in a CNF, such as image update or any virtual
20 resource modification, if the user fully terminates the CNFC to be modified on all
the sites.
[0093] While considerable emphasis has been placed herein on the disclosed
embodiments, it will be appreciated that many embodiments can be made and that
25 many changes can be made to the embodiments without departing from the
principles of the present disclosure. These and other changes in the embodiments
of the present disclosure will be apparent to those skilled in the art, whereby it is to
be understood that the foregoing descriptive matter to be implemented is illustrative
and non-limiting.
35
We Claims:
1. A method for managing one or more container network function (CNF)
nodes, the method comprising:
receiving, by 5 a processing unit [302], a containerized
network function component (CNFC) instantiation request at a
container network function life cycle manager (CNF-LM) with an
input associated with a deployment plan via a user interface;
sending, by the processing unit [302], a resource reserving
10 request to a policy execution engine (PEEGN) from the CNF-LM
based on the received CNFC instantiation request;
receiving, by the processing unit [302], a response at the
CNF-LM from the PEEGN for a successful reservation request;
sending, by the processing unit [302], the CNFC
15 instantiation request to a Docker Service Adapter (DSA) from the
CNF-LM for instantiation of the one or more CNFC(s);
initiating, by the processing unit [302], at a Docker host via
the DSA, the instantiation of one or more CNFC(s) of CNF based
on the CNFC instantiation request and the input associated with the
20 deployment plan; and
receiving, by the processing unit [302], an instantiation
status from the Docker host at the CNF-LM related to the
instantiation of the one or more CNFC(s) of the CNF.
25 2. The method as claimed in claim 1, wherein the CNFC instantiation request
comprises a number of instantiated CNFs, a number of CNFs in a pending
state along with a table containing CNF name, CNF version, a number of
CNFCs, CNFC version, vendor name, status being at least one of pending
or completed, and timestamp.
30
36
3. The method as claimed in claim 1, wherein receiving the input associated
with the deployment plan comprises CNFC names with different version
numbers, regional site, pod name, instantiation order, CNFC resource
constraints, and policy.
5
4. The method as claimed in claim 1, further comprises storing the
instantiation status, CNF details, CNFC details, deployment plan status,
host name, container ID in a storage unit [308] of a Physical Virtual
Inventory Manager (PVIM) [210].
10
5. The method as claimed in claim 1, wherein managing the one or more CNFs
comprises: updating, modifying, instantiating, re-instantiating, and
terminating one or more CNFCs from one or more CNFs in the deployment
plan without terminating functioning of the CNF, with changes in image,
15 and resource inputs.
6. The method as claimed in claim 1, further comprises:
sending an instantiation status update to a Release Management
Repository (RMR) from the CNF-LM; and
20 sending a CNF instantiation response to the user interface for the
received CNFC instantiation request upon receiving a status update
response from the RMR.
7. A system for managing one or more container network function (CNF)
25 nodes, the system comprising:
- a processing unit [302] configured to:
receive a CNFC instantiation request at a container network
function life cycle manager (CNF-LM) with an input associated
with a deployment plan via a user interface;
37
send a resource reserving request to a policy execution
engine (PEEGN) via the CNFLM based on the received CNFC
instantiation request;
receive a response at the CNF-LM from the PEEGN for a
5 successful reservation request;
send the CNFC instantiation request to a Docker Service
Adapter (DSA) from the CNFLM for instantiation of the one or
more CNFC(s);
initiate, at a Docker host via the DSA, the instantiation of
10 one or more CNFC(s) of CNF based on the CNFC instantiation
request and the input associated with the deployment plan; and
receive an instantiation status from the Docker host at the
CNFLM related to the instantiation of the one or more CNFC(s)
of the CNF.
15 8. The system as claimed in claim 7, wherein the CNFC instantiation request
comprises a number of instantiated CNFs, a number of CNFs in a pending
state along with a table containing CNF name, CNF version, a number of
CNFCs, CNFC version, vendor name, status, and timestamp.
20 9. The system as claimed in claim 7, wherein the input associated with the
deployment plan comprises CNFC names with different version numbers,
regional site, pod name, instantiation order, CNFC resource constraints, and
policy.
25 10. The system as claimed in claim 7, wherein the processing unit is further
configured to store the instantiation status, CNF details, CNFC details,
deployment plan status, host name, container ID in a storage unit [304] of a
Physical Virtual Inventory Manager (PVIM) [210].
38
11. The system as claimed in claim 7, wherein management of the one or more
CNF corresponds to update, modify, instantiate, re-instantiate, and
terminate one or more CNFCs from one or more CNFs in the deployment
plan without terminating the functioning of the CNF, with changes in image,
5 and resource inputs.
12. The system as claimed in claim 7, wherein the processing unit is configured
to:
send an instantiation status update to a Release Management
10 Repository (RMR) from the CNFLM; and
send a CNF instantiation response to the user interface for the
received CNFC instantiation request upon receiving a status update
response from the RMR.