Virtual Network Functions Load Balancer

Abstract

Examples may include techniques for routing packets to virtual network functions. A network function virtualization load balancer is provided that can route packets so as to maximize a specified distribution and minimize context switching between virtual network functions. The virtual network functions are arranged to enable context transfer from one virtual network function to another virtual network function. Thus, the system can be managed, such as scaled up or down, regardless of the statefulness of the virtual network functions and their local contexts or flows.

Description

Technical Field

[0001] Examples described herein relate generally to configurable computing resources and specifically to managing virtual network functions. Background Art

[0002] Modern computing technologies often employ virtualization. Virtualization has expanded from single applications (such as virtualized operating systems) to virtualization of network functions. As network function virtualization is deployed in “cloud” based systems, the ability to perform debugging, capacity planning, and device management becomes increasingly complex. This is especially true when considering the interdependencies between virtual network functions. BRIEF DESCRIPTION OF THE DRAWINGS

[0003] Figure 1 An exemplary first system is shown.

[0004] Figure 2 An exemplary second system is shown.

[0005] Figure 3 An exemplary third system is shown.

[0006] Figure 4 An exemplary fourth system is shown.

[0007] Figure 5 An exemplary fifth system is shown.

[0008] Figure 6 An exemplary network functions virtualization load balancer is shown.

[0009] Figure 7 Example virtual network functions are shown.

[0010] Figure 8 Example techniques for load-balanced packet routing in a system with stateful virtual network functions are shown.

[0011] Fig. 9 An example of a storage medium is shown.

[0012] Fig.10 An exemplary computing platform is shown. DETAILED DESCRIPTION

[0013] Typically, network function virtualization (NFV) deployments are intended to replace dedicated hardware devices with virtual devices, for example to enable the consolidation of several dedicated network devices onto virtual servers, switches, and storage devices. NFV deployments can include multiple network functions implemented in software. These are often referred to as virtual network functions (VNFs). VNFs can be instantiated as needed at various locations in a network using virtualized servers, often referred to as "cloud" computing or "fabric" computing.

[0014] However, many VNFs are interdependent on each other. This is often referred to as VNFs being stateful. In other words, the operation of VNFs, i.e. their functionality, can depend on the state of other VNFs within the NFV deployment, the previous state of the VNF, etc. Therefore, scaling NFV deployments must take into account the statefulness of VNFs within the NFV deployment. Of particular interest is scaling down NFV deployments (e.g., reducing the number of VNFs based on demand, etc.) or migrating VNFs from one virtual server to another.

[0015] Conventionally, once instantiated, a VNF cannot be moved or de-instantiated unless there is no longer any affinity with that VNF. As a result, these VNF instances will continue to use up resources, preventing efficient use of the infrastructure, preventing security patches from being applied to virtual servers, etc. Furthermore, rebalancing resources is problematic because VNFs cannot be moved in a conventional manner.

[0016] The present disclosure provides a NFV load balancer, which is arranged to route services to VNFs deployed across virtualized servers. The NFV load balancer can route services to some VNFs in the VNF based on the dependencies of the VNFs and based on the specified distribution across the VNFs. An NFV database (DB) is provided to store indications of dependencies or contexts of the VNFs. The VNFs can be arranged to query the NFV DB to determine the context of the received packets. Therefore, dependencies and / or "processes" can be migrated between VNFs. In this way, a system in which a NFV load balancer, NFV DB, and VNFs are deployed can instantiate and / or cancel instantiation of new VNF instances, and can change the specified service allocation across VNFs as needed to manage resources in the system. In some examples, the NFV load balancer can be implemented according to various standards promulgated by the European Telecommunications Standards Institute (ETSI).

[0017] Reference is now made to the accompanying drawings, in which the same reference numerals are used to refer to the same elements throughout. In the following description, for the purpose of explanation, many specific details are set forth in order to provide a thorough understanding thereof. However, it may be apparent that novel embodiments may be practiced without these specific details. In other cases, known structures and devices are shown in block diagram form to facilitate description thereof. The purpose is to provide a comprehensive description so that all modifications, equivalents, and alternatives within the scope of the claims are fully described.

[0018] Additionally, reference may be made to variables such as "a," "b," and "c" used to represent components where more than one component may be implemented. It should be noted that multiple components are not necessarily required, and, where multiple components are implemented, they do not have to be identical. Rather, the use of variables to refer to components in the diagrams is for convenience and clarity of presentation.

[0019] Figure 1 An exemplary first system 100 is shown. In some examples, the system 100 includes a decomposed physical element 110, a composite element 120, a virtualized element 130, a workload element 140, a NFV load balancer 150, and a NFV database (DB) 160. In some examples, the NFV load balancer 150 can be arranged to manage or control at least some aspects of the decomposed physical element 110, the composite element 120, the virtualized element 130, and the workload element 140. More specifically, the NFV load balancer 150 is arranged to manage the flow of traffic to virtual network functions (VNFs) (e.g., VNFs 136-1 to 136-n, etc.) within the system 100. With some examples, the NFV load balancer 150 can route traffic to the VNFs based on various metrics of the VNFs (e.g., resource utilization, latency, network throughput, etc.), dependencies or known contexts, and a specified routing distribution. The NFV DB 160 can be arranged to store context and / or associated indications of each VNF within the system 100. During operation, a VNF (e.g., VNFs 136-1 to 136-n) may be arranged to query NFV DB 160 and / or other VNFs to obtain context, where the context of an incoming packet is unknown. This is described in more detail below. The overall management and operation of the system 100 may be performed by a coordinator (see Figure 2-3 ) etc to promote.

[0020] Using some examples, such as Figure 1As shown, the decomposed physical element 110 may include CPUs 112-1 to 112-n, where "n" is any positive integer greater than 1. CPUs 112-1 to 112-n may individually represent a single microprocessor, or may represent discrete cores of a multi-core microprocessor. The decomposed physical element 110 may also include memories 114-1 to 114-n. Memories 114-1 to 114-n may represent various types of memory devices, such as, but not limited to, dynamic random access memory (DRAM) devices that may be included in dual in-line memory modules (DIMMs) or other configurations. The decomposed physical element 110 may also include storage devices 116-1 to 116-n. Storage devices 116-1 to 116-n may represent various types of storage devices, such as hard disk drives or solid-state drives. The decomposed physical element 110 may also include network (NW) input / output (I / O) 118-1 to 118-n. The NW I / O 118-1 to 118-n may include a network interface card (NIC) or host fabric interface (HFI) having one or more NW ports w / associated media access control (MAC) functionality for network connections within or outside the system 100. The decomposed physical element 110 may also include NW switches 119-1 to 119-n. The NW switches 119-1 to 119-n may be capable of routing data via internal or external network links for elements of the system 100.

[0021] The combined element 120 may include logical servers 122-1 to 122-n. For example, groups of CPU, memory, storage, NW I / O, or NW switch elements from the decomposed physical element 110 may be combined to form logical servers 122-1 to 122-n. Each logical server may include any number of CPU, memory, storage, NW I / O, or NW switch elements or combinations thereof.

[0022] The virtualization element 130 may include a number of virtual machines (VMs) 132-1 to 132-n, virtual switches (vSwitches) 134-1 to 134-n, virtual network functions (VNFs) 136-1 to 136-n, or containers 138-1 to 138-n. It should be appreciated that the virtual element 130 may be configured to implement a variety of different functions and / or execute a variety of different applications. For example, VM 132-a may be any of a variety of virtual machines configured to operate or behave as a dedicated machine, and a separate operating system may be executed as part of the VM. VNF 136-a may be any of a variety of network functions, such as packet inspection, intrusion detection, accelerators, etc. Container 138-a may be configured to execute or perform a variety of applications or operations, such as, for example, email processing, network services, application processing, data processing, etc.

[0023] Virtualized elements 130 may be arranged to form workload elements 140, also referred to as virtual servers. Workload elements may include any combination of virtualized elements 130, composite elements 120, or elements in decomposed physical elements 110. Workload elements may be organized into compute nodes or nodes 142-1 through 142-n.

[0024] Figure 2 An example system 200 is depicted. System 200 may be Figure 1 2 is an exemplary implementation of system 100. It is worth noting that system 200 includes references to elements from system 100. However, this is done for the purpose of clarity and brevity and is not intended to be limiting. Figure 2 As shown, system 200 may include logical servers 122-1 and 122-2. Each of logical servers 122-1 and 122-2 may host one or more VNFs 136-a. For example, logical server 122-1 is depicted hosting VNF 136-1 and VNF 136-2, while logical server 122-2 is depicted hosting VNF 136-3 and VNF 136-4. VNFs 136-1 to 136-4 may be communicatively coupled to NFV DB 160. For example, VNFs 136-1 to 136-4 may be coupled to NFV DB 160 via link 211. For some examples, NFV DB 160 may be a distributed DB. For example, each of VNFs 136-1 to 136-4 may implement a portion of NFV DB 160. For some examples, NFV DB 160 may be a combination of a dedicated database and a distributed database. For example, VNFs 136-1 to 136-4 may be combined to implement a portion of NFV DB 160, while balancing of the database is implemented as a dedicated entity.

[0025] The system 200 includes a coordination layer or orchestrator 170. The orchestrator 170 is coupled to the VNFs 136-1 through 136-4 and to the NFV load balancer 150. In general, the orchestrator 170 may be arranged to centralize management and control of the elements of the system 200. That is, the orchestrator 170 may control the combination of the decomposed physical resources 110 to form the composite element 120, and may control the instantiation of the virtualized elements 130 onto the composite element 120. The NFV load balancer 150 is coupled to the VNFs 136-1 through 136-4 via the links 215.

[0026] For some examples, links 211, 213, and / or 215 may be connected through a vSwitch (e.g., Figure 1In addition, any of a variety of signaling techniques may be used to enable communication via links 211, 213, and / or 215, such as, for example, Virtual Extensible LAN (VXLAN), Remote Direct Memory Access (RDMA), Omni- wait.

[0027] During operation, the system 200 may (e.g., via Figure 1 The vSwitch 134-a in the NFV load balancer 150, etc.) receives network traffic or packets 220 and may route the packets to the VNFs 136-1 to 136-4 for processing. Generally, the NFV load balancer 150 may route packets 220 to the VNFs 136-1 to 136-4 to accommodate a desired or specified distribution while minimizing the time that the VNF 136-a routes packets for which it has no context. As used herein, the term "context" when related to packets and VNFs is intended to imply that the VNF has some association, dependency, knowledge, or statefulness with respect to the packet. Thus, during operation, the NFV load balancer 150 may route packets 220 to the VNFs 136-1 to 136-4 to accommodate a specified distribution and minimize the switching of context between the VNFs. This is described in more detail below (see, for example, Figure 4-8 ).

[0028] Each VNF (e.g., VNF 136-1 to 136-4) may apply the same processing flow to packets when receiving packet 220 from NFV load balancer 150. This processing flow is described in more detail below (e.g., see Figure 7-8 ). However, in general, VNFs 136-1 to 136-4 can parse received packets, extract fields to identify flows, and determine associated contexts. In some examples, contexts can be determined based on internal data structures, by requesting contexts from another VNF, by requesting contexts from a database (e.g., NFV DB 160, etc.). During operation, packets can be processed and contexts determined by VNFs (e.g., VNFs 136-1 to 136-4), and each VNF can report telemetry (e.g., indications of resource utilization, etc.) to NFV load balancer 150.

[0029] In some examples, multiple NFV load balancers may be provided. For example, Figure 3 An example system 300 is illustrated. The system 300 may be Figure 1 System 100 or Figure 2 200. Note that system 300 includes references to elements from both systems 100 and 200. However, this is done for the sake of clarity and brevity and is not limiting. Figure 3 As shown, system 300 also includes a local NFV load balancer deployed on each logical server in addition to NFV load balancer 150. For example, the figure depicts logical server 122-1 including VNFs 136-1 and 136-2 and local NFV load balancer 310-1, while logical server 122-2 is depicted as including VNFs 136-3 and 136-4 and local NFV load balancer 310-2.

[0030] The local NFV load balancers 310-1 and 310-2 are each coupled to the NFV load balancer 150 (represented in the figure as the primary NFV load balancer 150) and the respective VNF 136-a via link 215. During operation, the primary NFV load balancer 150 can receive the packet 220 and route the packet 220 to the local NFV load balancer 310-a. For example, the primary NFV load balancer 150 can receive the packet and route the packet to the local NFV load balancer 310-1 or route the packet to the local NFV load balancer 310-2. Subsequently, the local NFV load balancer 310-a can route the packet to the VNF instantiated within the corresponding logical server in which the local NFV load balancer is implemented. Typically, the primary NFV load balancer 150 and the local NFV load balancer 310-a can route the packet 220 to accommodate the desired or specified distribution while minimizing the number of context switches between the VNFs 136-1 to 136-4.

[0031] Figure 4-5 An example of a specified or desired distribution of packet routing across a set of VNFs is depicted. Specifically, Figure 4 An example system 400 is depicted with a single NFV load balancer and a specified routing distribution of VNFs within the system 400, while Figure 5 An example system 500 is depicted, with a primary NFV load balancer and local NFV load balancers and a specified routing distribution for each level. Systems 400 and 500 may be Figure 1 System 100, Figure 2 System 200 and / or Figure 3 An example implementation of system 300 is provided. Note that systems 400 and 500 include references to elements from systems 100, 200, and / or 300. However, this is done for the sake of clarity and brevity and is not limiting. Additionally, it is noteworthy that the NFV load balancer routes packets to accommodate the specified distribution and minimize context switching between VNFs. As such, in some examples, the routing may not fully accommodate the specified distribution. This is described in more detail below.

[0032] More specifically, turn to Figure 4, system 400 includes logical server 122-1, logical server 122-2, and logical server 122-3. Each of logical servers 122-1 through 122-3 can host one or more VNFs 136-a. For example, logical server 122-1 is depicted hosting VNF 136-1 and VNF 136-2. Logical server 122-2 is depicted hosting VNF 136-3 and VNF 136-4; and logical server 122-3 is depicted hosting VNFs 136-5 and 136-6.

[0033] The NFV load balancer 150 may be arranged to route the packets 220 to fit the specified distribution 410. For example, the specified distribution 410 depicted in this figure is shown in the following table:

[0034]

[0035]

[0036] Table 1: Example distribution of system 400

[0037] Note that the example distribution 410 shown in the figure and given in the table above is provided for illustration purposes only. For some examples, the specified distribution 410 may be generated by the NFV load balancer 150, the orchestrator 170, or provided by a customer, such as specified in a service level agreement (SLA), etc. For some examples, the specified distribution 410 may be linear.

[0038] More specifically, turn to Figure 5 , system 500 includes logical server 122-1, logical server 122-2, and logical server 122-3. Each of logical servers 122-1 through 122-3 can host one or more VNFs 136-a. For example, logical server 122-1 is depicted hosting VNF 136-1 and VNF 136-2; logical server 122-2 is depicted hosting VNF 136-3 and VNF 136-4; and logical server 122-3 is depicted hosting VNFs 136-5 and 136-6.

[0039] In addition, the system 500 includes a local NFV load balancer 310-a for each logical server 122-a. For example, the system 500 is depicted as including local NFV load balancers 310-1, 310-2, and 310-3 coupled to logical servers 122-1 through 122-3, respectively. The primary NVF load balancer 150 is coupled to the local NFV load balancer 310-a.

[0040] The primary NFV load balancer 150 may be arranged to route the packet 220 to the local NFV load balancer to fit the specified distribution 520, while the local NFV load balancer 310-a may be arranged to route the packet 220 to the corresponding VNF 136-a to fit the specified distribution 510. For example, the specified distributions 510 and 520 are depicted in the figure, which are shown in the following table:

[0041]

[0042] Table 2: Example distribution of system 500

[0043] Note that the example distributions 510 and 520 depicted in the figure and given in the table above are for illustration purposes only. For some examples, the specified distributions 510 and 520 may be generated by the NFV load balancer, orchestrator 170, or provided by a customer, such as specified in a service level agreement (SLA), etc. For some examples, the specified distributions 510 and / or 520 may be linear.

[0044] Figure 6 An exemplary NFV load balancer 600 is depicted. The NFV load balancer 600 may be implemented as the NFV load balancer 150 from any of the systems 100, 200, 300, 400, or 500. In addition, the NFV load balancer 600 may be implemented as one of the local NFV load balancers 310-a from any of the systems 300 or 500. As shown, the NFV load balancer 600 may include a parameter module 610, a packet parser 620, a flow identifier 630, a flow counter 640, a packet router 650, and a VNF distribution counter 660.

[0045] In general, the NFV load balancer 600 may be implemented as hardware, software, or a combination of hardware and software. For example, in some implementations, the NFV load balancer 600 may be implemented using an application specific integrated circuit, a field programmable gate array, a digital logic component, etc., which is arranged to operate as detailed herein. In other examples, the NFV load balancer 600 may include a processor component and a memory, the memory including instructions executable by the processor component, the execution of which causes the processor component to operate as detailed herein (see Fig.10 ). In this context, the examples are not limited.

[0046] Typically, the NFV load balancer 600 operates as follows. Network traffic, such as packet 220, is received at a packet parser 620. The packet parser 620 extracts fields from the packet 220. Typically, the packet parser 620 can extract any of a variety of fields from the incoming packet. However, in practice, the packet parser 620 can extract fields from the incoming packet 220 to determine the context or "flow" associated with the packet. In some implementations, the packet parser 620 can extract components of the packet, such as, for example, tuple components of a Transmission Control Protocol (TCP) Internet Protocol (IP) (TCP / IP) packet (e.g., 5-tuples, 12-tuples, etc.). In some implementations, the packet parser 620 can extract address components of the packet (e.g., media access control (MAC), sender MAC, destination MAC, or sender / destination MAC pair, etc.).

[0047] The NFV load balancer 600 may receive an information element and / or a control signal from the coordinator 170, which may include an indication of a field extracted from an incoming packet. For example, in some implementations, the parameter module 610 may receive an information element including an indication of a field extracted from the incoming packet 220. During operation, the packet parser 620 may extract the field from the incoming packet 220 based on the indication received by the parameter module 610.

[0048] The flow identifier 630 can determine a "flow" or context for the incoming packet 220 based on the extracted fields. In some examples, the flow identifier 630 can implement a hash table to map the extracted fields to a flow. In some examples, the flow identifier 630 can implement a bit mask, a table tree, an access control list, etc. to map the extracted fields to a flow. As a specific example, the flow identifier can implement a hash function on the extracted fields to map the extracted fields to a "hash bucket" that corresponds to a flow or context for the incoming packet.

[0049] Flow counter 640 may count the number of times a context or flow is identified by flow identifier 630. For example, flow counter 640 may determine each time a particular flow is identified based on hashing the extracted fields by flow identifier and may increment the counter for the particular flow.

[0050] The NFV load balancer 600 may receive an information element and / or a control signal from the coordinator 170, which may include an indication of a hash function. For example, in some implementations, the parameter module 610 may receive an information element including an indication that a hash function is implemented by the flow identifier 630. Thus, during operation, the flow identifier 630 may use the received hash function to hash the fields of the extracted packet 220 to identify the flow bucket.

[0051] The packet router 650 may map incoming packets to VNFs (e.g., VNF 136-a, etc.) based on the flows identified by the flow identifier 630 and based on the specified distribution. As described above, the packet router 650 routes the incoming packets 220 to the VNFs to satisfy the specified distribution while minimizing context switches between the VNFs. In some examples, the packet router 650 may implement an algorithm to route packets to maximize the specified distribution while minimizing context switches between the VNFs.

[0052] The NFV load balancer 600 may receive information elements and / or control signals from the coordinator 170, which may include an indication of a specified distribution. For example, in some implementations, the parameter module 610 may receive an information element including an indication of a specified distribution (e.g., distributions 410, 510, and 520, etc.). During operation, the packet router 650 may route packets based on the indication received by the parameter module 610 and the identified flow.

[0053] For some implementations, the NFV load balancer 150 may implement risk distribution techniques. For example, the NFV load balancer 150 may route a single packet 220 to multiple VNFs for redundancy and / or high availability implementations. Thus, a routing table including VNFs with contexts or indications of VNFs for which the context associated with a packet is local to the VNF may include multiple VNFs for a single context. Thus, packets may be routed to multiple VNFs in parallel.

[0054] The VNF distribution counter 660 can count the number of times the packet 220 is routed to each respective VNF (e.g., VNF 136-a, etc.). For example, the VNF flow counter 640 can determine each time a particular VNF is routed a packet 220 and can increment the counter for the particular VNF.

[0055] In some implementations, the NFV load balancer 600 may be arranged to minimize routing of packets of the same context to different VNFs. In other words, the NFV load balancer 600 may be arranged to minimize the shuffling of contexts between VNFs, which causes the transmission of packet contexts between VNFs or from the NFV DB to the VNF. To this end, the NFV load balancer 600 is arranged to calculate (e.g., periodically, repeatedly, continuously, etc.) the actual distribution of packet routes to the VNFs, and determine modifications (or changes) in the routes that move the actual distribution closer to the specified distribution (e.g., distributions 410, 510, and 520, etc.).

[0056] Thus, the flow counter 640 may be arranged to determine the hash bucket corresponding to the incoming packet, and the VNF distribution counter 660 may be arranged to count the number of times the packet is routed through each hash bucket. The NFV load balancer 600 or packet router 650 may determine which VNFs are to route the packet to achieve the specified distribution based on the determined hash buckets and the count of the number of times the packet has been routed through each bucket.

[0057] As described above, in some examples, the packet router 650 may route a packet to a new VNF whose packet context is a packet context, generating a shuffle of the packet context, or moving the packet context from another VNF or NFV DB to the VNF receiving the packet. In some implementations, the packet router 650 may be arranged to limit the rate at which context shuffles occur. For example, the packet router 650 may be arranged to limit the routing of packets to generate context offsets that are less than a threshold number (e.g., 1 context offset per 1 second, etc.) within a specified time. This threshold amount is sometimes referred to as a threshold context switch limit.

[0058] Figure 7 An example VNF 700 is depicted. VNF 700 may be implemented as any of the VNFs 136-a from any of the systems 100, 200, 300, 400, or 500. As depicted, VNF 700 may include a packet parser 710, a flow matcher 720, an NFV DB query module 730, and a core VNF module 740. As described above, in many implementations, a VNF such as VNF 700 is stateful. That is, VNF 700 may include one or more packet contexts 750 associated in a packet 220 to be received. Core VNF module 740 may utilize packet context 750 to process packets and implement core VNF functionality. Additionally, in some examples, VNF 700 may include a telemetry exposer 760.

[0059] During operation, network traffic, such as packet 220, is received at packet parser 710 from a NFV load balancer (e.g., NFV load balancer 150, local NFV load balancer 310, etc.). Packet parser 710 extracts fields from packet 220. Typically, packet parser 710 may extract any of a variety of fields from an incoming packet. However, in practice, packet parser 710 may extract fields from incoming packet 220 to determine a context or "flow" to which the packet is associated. In some implementations, packet parser 710 may extract components of a packet, such as, for example, tuple components (e.g., 5-tuples, 12-tuples, etc.) of a Transmission Control Protocol (TCP) Internet Protocol (IP) (TCP / IP) packet. In some implementations, packet parser 710 may extract address components of a packet (e.g., a media access control (MAC), a sender MAC, a destination MAC, or a sender / destination MAC pair, etc.).

[0060] As with the NFV load balancer 600, the VNF 700 may receive information elements and / or control signals from the coordinator 170, which may include indications of fields extracted from the incoming packet. The flow identifier 720 may determine the "flow" or context of the incoming packet 220 based on the extracted fields. In some examples, the flow identifier 720 may implement a hash table to map the extracted fields to the flow. In some examples, the flow identifier 720 may implement a bit mask, a table tree, an access control list, etc. to map the extracted fields to the flow. As a specific example, the flow identifier 720 may implement a hash function on the extracted fields to map the extracted fields to a "hash bucket" corresponding to the packet context 750.

[0061] For example, in the case where the flow matcher 720 determines (e.g., based on a hash operation of the extracted fields) that the packet context 750 of the received packet 220 is known, the flow matcher 720 may initiate processing of the received packet by the core VNF module 740. Alternatively, for example, in the case where the flow matcher 720 determines (e.g., based on a hash operation of the extracted fields) that the packet context 750 of the received packet 220 is unknown, the NFV DB query module 730 may query the NFV DB 160 for the packet context 750.

[0062] In some implementations, the NFV query module 730 may implement a queue (e.g., an asynchronous queue, etc.) in which received packets 220 are pipelined in the case where the packet context 750 is unknown. In some cases, the NFV query module 730 may receive an indication from the NFV DB 160 that the packet context is unknown. For example, in the case of a new (e.g., entering the system, etc.) flow. In such an example, the core VNF module 740 may process the received packet and start a new packet context 750 for the new flow. In some cases, the NFV query module 730 may return an indication of the packet context 750. For example, in the case of a rebalanced or transmitted flow. In such an example, the core VNF module 740 may use the received packet context 750 to process the received packet. In addition, the NFV DB 160 may mark the VNF 700 as the owner of the packet context.

[0063] The telemetry exposer 760 may provide indications of telemetry information 765 (eg, processor utilization, cache utilization, I / O, memory utilization, etc.) to the coordinator 160 .

[0064] Figure 8 An example technique 800 for load balancing of stateful VNFs is shown. In some examples, the technique 800 can be implemented by any of the systems described herein. For example, the technique 800 can be implemented by Figure 1 System 100, Figure 2 System 200, Figure 3 System 300, Figure 4 System 400, Figure 5 The technique 800 may be implemented in the system 500 and the like. The technique 800 may start at loop 8.1. At loop 8.1, the coordinator 170 may send an information element 801 to the NFV load balancer 150, including an indication of one or more settings for routing packets within the system 100. For example, the information element 801 may include an indication of packet fields to be extracted, a hash function to determine a context based on the extracted elements, a specified routing distribution, etc. At loop 8.2, the NFV load balancer 150 may receive the information element 801 including an indication of settings for routing packets within the system 100.

[0065] Continuing with circle 8.3, the NFV load balancer 150 may receive the packet 220. At circle 8.4, the NFV load balancer may extract fields from the packet 220. For example, the packet parser 620 may extract the fields from the packet 220. Continuing with circle 8.5, the NFV load balancer may determine a context or flow for the packet 220. For example, the flow identifier 630 may hash the fields of the packet 220 extracted at circle 8.4 to determine a flow or context bucket associated with the packet 220.

[0066] Continuing to circle 8.6, the VNF load balancer 150 may determine one of the VNFs 136 that owns the packet 220, or more specifically, one of the VNFs 136 that is associated with the packet 220 and has a context for a flow associated with the packet 220. For some examples, the NFV load balancer 150 may maintain an indication (e.g., a table, directory, bitmap, etc.) of VNF ownership of a context bucket determined by hashing fields extracted from the packet 220. Circle 8.6 may include circle 8.6A, at which the NFV load balancer 150 may determine the VNF 136 that owns the flow associated with the packet 220 from the maintained indication. In other examples, the NFV load balancer 150 may determine the VNF ownership of the context bucket from the NFV DB 160. For example, circle 8.6 may include circles 8.6B and 8.6C. At circles 8.6B and 8.6C, the NFV load balancer 150 may exchange information elements 803 with the NFV DB 160, including a request for an indication of the VNF that owns the flow associated with the packet 220 and a response from the NFV DB 160 including the indication of the VNF.

[0067] Continuing to circle 8.7, the NFV load balancer 150 may determine, based on various factors, the VNF 136 for routing the packet 220. As described above, the NFV load balancer 150 may make routing decisions based on maximizing compliance with the routing profile while minimizing movement (or switching) of context between VNFs.

[0068] Continue to loops 8.8 and 8.9. At loop 8.8, NFV load balancer 150 can route packet 220 to the VNF selected at loop 8.7 (e.g., VNF 136-1). At loop 8.9, the VNF (e.g., VNF 136-1) can receive the packet from NFV load balancer 150.

[0069] Continuing to circle 8.10, the VNF 136-1 can determine the context of the packet 220. For some implementations, the VNF 136-1 can extract fields from the packet 220 and hash the fields to determine the context. For example, the VNF 136-1 can implement the operations described above for circles 8.4 and 8.5. In some embodiments, the VNF 136-1 can retrieve the previously hashed bucket from the NFV load balancer. For example, the NFV load balancer 136 can transmit the previously determined context to the VNF as part of the routed packet 220.

[0070] Continuing to loop 8.11, VNF 136-1 may determine whether the context associated with packet 220 is local to the VNF. In other words, VNF 136-1 may determine whether VNF 136-1 owns the context associated with packet 220. Based on a determination that VNF ​​136-1 does own the context, technique 800 may jump to loop 8.15. However, based on a determination that VNF ​​136-1 does not own the context, technique 800 may continue to loop 8.12.

[0071] At circle 8.12, VNF 136-1 may query NFV DB 160 to determine the owner of the context associated with packet 220. For example, NFV DB query module 730 may send a request to NFV DB 160 for an indication of the owner of the context associated with packet 220. Continuing to circles 8.13 and 8.14, VNF 136-1 may add packet 220 to a processing queue while waiting for context 750. At circle 8.14, NFV DB 160 may send an information element 807 that includes an indication of the owner of the context associated with packet 220. In some examples, no owner is specified, in which case VNF 136-1 may initiate or create context 750. In other examples, one of VNFs 136-2 to 136-n is specified and may retrieve context 750 from NFV DB 160 and / or the specified VNF. Additionally, at circle 8.14, the NFVDB 160 may designate VNF 136-1 (eg, the VNF requesting the context) as the owner (or new owner) of the context.

[0072] At circle 8.15, VNF 136-1 may process packet 220 normally. VNF 136-1 may retrieve packet 220 from the queue and process the packet based on context 750 (e.g., context retrieved from other VNFs, context retrieved from NFV DB 160, or context created because the context is new to the system, etc.). Technique 800 may optionally include circle 8.16. At circle 8.16, VNF 136-1 may send information element 809 including an indication of telemetry information of VNF 136-1 to coordinator 170.

[0073] Continuing to circle 8.17, the orchestrator 170 can manage the VNFs within the system. For example, the orchestrator can instantiate new VNFs, can de-instantiate existing VNFs, can relocate VNFs from one logical server to another logical server (e.g., to provide proximity to the VNFs and packet origination, etc.), etc. In addition, the orchestrator 170 can update the specified distribution for routing packets 220 based on the updated telemetry information, and can return to circle 8.1 to provide the updated routing distribution to the NFV load balancer 150.

[0074] It is important to note that technique 800 can be extended to multiple levels of load balancing (eg, where there is a primary route and one or more levels of secondary routes).

[0075] Fig. 9 An example of a storage medium 900 is shown. The storage medium 900 may include an article of manufacture. In some examples, the storage medium 900 may include any non-transitory computer-readable medium or machine-readable medium, such as an optical, magnetic, or semiconductor storage device. The storage medium 900 may store various types of computer-executable instructions, such as instructions to implement the technique 800. Examples of computer-readable or machine-readable storage media may include any tangible medium capable of storing electronic data, including volatile or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writable or rewritable memory, and the like. Examples of computer-executable instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, object-oriented code, visual code, and the like. The examples are not limited in this context.

[0076] Fig.10 An embodiment of an exemplary computing architecture 1000 suitable for implementing various embodiments as described above is shown. In various embodiments, the computing architecture 1000 may include or be implemented as a part of an electronic device. In some embodiments, the computing architecture 1000 may, for example, represent a portion of the system 100, such as a NFV load balancer 150. The embodiments are not limited in this context.

[0077] As used in this application, the terms "system" and "component" and "module" are intended to refer to computer-related entities, which can be hardware, a combination of hardware and software, software, or software in execution, examples of which are provided by the exemplary computing architecture 1000. For example, a component can be, but is not limited to, a process running on a processor, a processor, a hard drive, multiple storage drives (of optical and / or magnetic storage media), an object, an executable file, an execution thread, a program, and / or a computer. For example, both an application running on a server and a server can be a component. One or more components can reside in a process and / or an execution thread, and a component can be located on a computer and / or distributed between two or more computers. In addition, components can be communicatively coupled to each other through various types of communication media to coordinate operations. Coordination may involve a unidirectional or bidirectional exchange of information. For example, a component can transmit information in the form of a signal transmitted through a communication medium. The information can be implemented as a signal assigned to various signal lines. In this assignment, each message is a signal. However, other embodiments may alternatively use data messages. Such data messages can be sent through various connections. Exemplary connections include parallel interfaces, serial interfaces, and bus interfaces.

[0078] The computing architecture 1000 includes various common computing elements, such as one or more processors, multi-core processors, coprocessors, memory units, chipsets, controllers, peripherals, interfaces, oscillators, timing devices, video cards, sound cards, multimedia input / output (I / O) components, power supplies, etc. However, the embodiments are not limited to being implemented by the computing architecture 1000.

[0079] like Fig.10 As shown, computing architecture 1000 includes a processing unit 1004, a system memory 1006, and a system bus 1008. Processing unit 1004 can be any of a variety of commercially available processors, including but not limited to and processor; Application, embedded and security processors; and and Processors; IBM and Cell processor; Core(2) and Dual microprocessors, multi-core processors, and other multi-processor architectures may also be used as the processing unit 1004 .

[0080] The system bus 1008 provides an interface for system components including, but not limited to, the system memory 1006 to the processing unit 1004. The system bus 1008 may be any of several types of bus structures, which may further interconnect to a memory bus (with or without a memory controller), a peripheral bus, and a local bus using any of a variety of commercially available bus architectures. Interface adapters may be connected to the system bus 1008 via a slot architecture. Exemplary slot architectures may include, but are not limited to, Accelerated Graphics Port (AGP), Cardbus, (Extended) Industry Standard Architecture ((E)ISA), Micro Channel Architecture (MCA), NuBus, Peripheral Component Interconnect (Extended) (PCI(X)), PCI Express, Personal Computer Memory Card International Association (PCMCIA), and the like.

[0081] The system memory 1006 may include various types of computer-readable storage media in the form of one or more higher-speed memory units, such as read-only memory (ROM), random access memory (RAM), dynamic RAM (DRAM), double data rate DRAM (DDRAM), synchronous DRAM (SDRAM), static RAM (SRAM), programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, polymer memory such as ferroelectric polymer memory, bidirectional memory, phase change or ferroelectric memory, silicon oxide nitride oxide silicon (SONOS) memory, magnetic or optical cards, device arrays such as redundant array of independent disks (RAID) drives, solid-state memory devices (e.g., USB memory, solid-state drive (SSD)), and any other type of storage medium suitable for storing information. Fig.10 In the illustrated embodiment shown, system memory 1006 may include non-volatile memory 1010 and / or volatile memory 1012. A basic input / output system (BIOS) may be stored in non-volatile memory 1010.

[0082] The computer 1002 may include various types of computer-readable storage media in the form of one or more lower-speed memory units, including an internal (or external) hard disk drive (HDD) 1014, a magnetic floppy disk drive (FDD) 1016 that reads from or writes to a removable magnetic disk 1018, and an optical drive 1020 that reads from or writes to a removable optical disk 1022 (e.g., a CD-ROM or DVD). The HDD 1014, FDD 1016, and optical drive 1020 may be connected to the system bus 1008 via a HDD interface 1024, an FDD interface 1026, and an optical drive interface 1028, respectively. The HDD interface 1024 for external drive implementations may include at least one or both of Universal Serial Bus (USB) and IEEE 1384 interface technologies.

[0083] The drives and associated computer-readable media provide volatile and / or non-volatile storage of data, data structures, computer-executable instructions, etc. For example, a number of program modules may be stored in the drives and memory units 1010, 1012 including an operating system 1030, one or more application programs 1032, other program modules 1034, and program data 1036. In one embodiment, the one or more application programs 1032, other program modules 1034, and program data 1036 may include, for example, various applications and / or components of the NFV load balancer 150 and / or VNF 136-a.

[0084] A user may enter commands and information into the computer 1002 through one or more wired / wireless input devices, such as a keyboard 1038 and a pointing device such as a mouse 1040. Other input devices may include a microphone, an infrared (IR) remote control, a radio frequency (RF) remote control, a game controller, a stylus, a card reader, a dongle, a fingerprint reader, a glove, a drawing tablet, a joystick, a keyboard, a retina reader, a touch screen (e.g., capacitive, resistive, etc.), a trackball, a trackpad, a sensor, a stylus, etc. These and other input devices are typically connected to the processing unit 1004 through an input device interface 1042 coupled to the system bus 1008, but may be connected through other interfaces, such as a parallel port, an IEEE 1384 serial port, a game port, a USB port, an IR port, etc.

[0085] A monitor 1044 or other type of display device is also connected to the system bus 1008 via an interface, such as a video adapter 1046. The monitor 1044 may be internal or external to the computer 1002. In addition to the monitor 1044, computers typically include other peripheral output devices, such as speakers, printers, and the like.

[0086] The computer 1002 can operate in a networking environment using logical connections to one or more remote computers, such as remote computer 1048, via wired and / or wireless communications. The remote computer 1048 can be a workstation, server computer, router, personal computer, portable computer, microprocessor-based entertainment device, peer device, or other public network node, and typically includes many or all of the elements described with respect to the computer 1002, although for simplicity, only the memory / storage device 1050 is shown. The depicted logical connections include wired / wireless connections to a local area network (LAN) 1052 and / or a larger network, such as a wide area network (WAN) 1054. Such LAN and WAN networking environments are common in offices and companies, and facilitate enterprise-wide computer networks, such as intranets, all of which can be connected to a global communication network, such as the Internet.

[0087] When used in a LAN networking environment, the computer 1002 is connected to the LAN 1052 through a wired and / or wireless communication network interface or adapter 1056. The adapter 1056 can facilitate wired and / or wireless communication to the LAN 1052, which can also include a wireless access point disposed thereon for communicating with the wireless functionality of the adapter 1056.

[0088] When used in a WAN networking environment, the computer 1002 may include a modem 1058, or be connected to a communications server on the WAN 1054, or have other means for establishing communications over the WAN 1054 (such as over the Internet). The modem 1058, which may be internal or external and a wired and / or wireless device, is connected to the system bus 1008 via the input device interface 1042. In a networking environment, program modules depicted relative to the computer 1002, or portions thereof, may be stored in the remote memory / storage device 1050. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.

[0089] The computer 1002 is operable to communicate with wired and wireless devices or entities using the IEEE 802 family of standards, such as wireless devices operatively arranged in wireless communications (e.g., IEEE 802.16 over-the-air modulation techniques). This includes at least Wi-Fi (or Wireless Fidelity), WiMax, and Bluetooth. TMWireless technology, etc. Therefore, the communication can be a predefined structure like a conventional network, or just an ad hoc communication between at least two devices. Wi-Fi networks use radio technologies called IEEE 802.11x (a, b, g, n, etc.) to provide secure, reliable, and fast wireless connections. Wi-Fi networks can be used to connect computers to each other, to the Internet, and to wired networks (using IEEE 802.3 related media and functions).

[0090] One or more aspects of at least one embodiment may be implemented by representative instructions stored on a machine-readable medium, which represents various logics within a processor, which when read by a machine enables the machine to manufacture logic to perform the techniques described herein. Such representations, referred to as "IP cores", may be stored on tangible machine-readable media and provided to various customers or manufacturing facilities to be loaded into manufacturing machines that actually manufacture logic or processors. Some embodiments may be implemented, for example, using a machine-readable medium or article, which may store instructions or sets of instructions, and if the machine executes the instructions or sets of instructions, the machine may be enabled to perform methods and / or operations according to the embodiments. Such a machine may include, for example, any suitable processing platform, computing platform, computing device, processing device, computing system, processing system, computer, processor, etc., and may be implemented using any suitable combination of hardware and / or software. The machine-readable medium or article may include, for example, any suitable type of memory unit, memory device, memory article, memory medium, storage device, storage article, storage medium and / or storage unit, such as memory, removable or non-removable media, erasable or non-erasable media, writable or rewritable media, digital or analog media, hard disk, floppy disk, compact disk read only memory (CD-ROM), compact disk recordable (CD-R), compact disk rewritable (CD-RW), optical disk, magnetic media, magneto-optical media, removable memory cards or diskettes, various types of digital versatile discs (DVDs), magnetic tapes, cassettes, etc. The instructions may include any suitable type of code implemented using any suitable high-level, low-level, object-oriented, visual, compiled and / or interpreted programming language, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, encrypted code, etc.

[0091] Example 1. An apparatus comprising: a circuit, at least a portion of which is implemented in hardware, the circuit being used to: extract at least one field from a packet; determine a context associated with the packet based on the at least one field; identify a first virtual network function (VNF) among a plurality of VNFs that is associated with the determined context and route the packet to one of the plurality of VNFs based at least in part on the context, the identified first VNF, and a target routing distribution of the plurality of VNFs.

[0092] Example 2. The apparatus of claim 1, wherein the one VNF is the first VNF.

[0093] Example 3. An apparatus as described in claim 1, wherein the circuit is used to maximize compliance with the target routing distribution and minimize routing the packet to the one VNF of the plurality of VNFs that is different from the first VNF.

[0094] Example 4. The apparatus of claim 1, said circuitry to compute a hash function on the at least one field from the packet to determine the context.

[0095] Example 5. An apparatus according to claim 4, wherein the circuit is used to: determine a hash bucket corresponding to the determined context based on the calculated hash function; count the number of times the packet has been routed to the hash bucket; and select the one of the multiple VNFs to route the packet to it based at least in part on the determined hash bucket and the number of times the packet has been routed to the hash bucket.

[0096] Example 6. The apparatus of claim 5, said circuitry to determine the hash bucket based on the target routing distribution.

[0097] Example 7. The apparatus of claim 1, wherein the circuitry limits routing of the packet to the one of the plurality of VNFs that is different from the first VNF ​​based on a threshold context switch limit.

[0098] Example 8. The apparatus of claim 1, wherein the one VNF is not the first VNF.

[0099] Example 9. An apparatus according to claim 1, wherein the circuit is used to: determine whether one of the multiple VNFs is associated with the context based on a routing table; and identify the first VNF ​​as the one of the multiple VNFs based on determining that the one of the multiple VNFs is associated with the context.

[0100] Example 10. An apparatus according to claim 1, wherein the circuit is used to route the packet to a second VNF among the multiple VNFs in parallel with routing the packet to the one VNF among the multiple VNFs based at least in part on the context, the identified first VNF, and the target routing distribution of the multiple VNFs.

[0101] Example 11. A system comprising: multiple virtual network functions (VNFs) hosted on one or more logical servers; a memory comprising a network function virtualization (NFV) database (DB) coupled to the one or more logical servers, the NFV DB comprising an indication of contexts associated with the multiple VNFs; and a NFV load balancer comprising circuits, at least a portion of which is implemented in hardware, the circuits being used to: extract at least one field from a packet; determine a context associated with the packet based on the at least one field; identify a first VNF ​​among the multiple VNFs that is associated with the determined context; and route the packet to one of the multiple VNFs based at least in part on the context, the identified first VNF, and a target routing distribution of the multiple VNFs.

[0102] Example 12. The system of claim 11, wherein the one VNF is the first VNF.

[0103] Example 13. The system of claim 11, wherein the circuit is configured to maximize compliance with the target routing profile and minimize routing the packet to the one of the plurality of VNFs that is different from the first VNF.

[0104] Example 14. The system of claim 11, the circuitry to compute a hash function on the at least one field from the packet to determine the context.

[0105] Example 15. A system according to claim 14, wherein the circuit is used to: determine a hash bucket corresponding to the determined context based on the calculated hash function; count the number of times the packet has been routed to the hash bucket; and select the one of the multiple VNFs to route the packet to it based at least in part on the determined hash bucket and the number of times the packet has been routed to the hash bucket.

[0106] Example 16. The system of claim 15, said circuitry to determine the hash bucket based on the target routing distribution.

[0107] Example 17. The system of claim 11, wherein the circuitry limits routing of the packet to the one of the plurality of VNFs that is different from the first VNF ​​based on a threshold context switch limit.

[0108] Example 18. The system of claim 11, wherein the one VNF is not the first VNF.

[0109] Example 19. According to the system of claim 11, the circuit is used to: determine whether one of the multiple VNFs is associated with the context based on a routing table; and identify the first VNF ​​as the one of the multiple VNFs based on determining that the one of the multiple VNFs is associated with the context.

[0110] Example 20. A system according to claim 11, wherein the circuit is used to: route the packet to a second VNF among the multiple VNFs in parallel with routing the packet to the one VNF among the multiple VNFs based at least in part on the context, the identified first VNF, and the target routing distribution of the multiple VNFs.

[0111] Example 21. A method comprising: extracting at least one field from a packet; determining a context associated with the packet based on the at least one field; identifying a first virtual network function (VNF) among a plurality of VNFs that is associated with the determined context; and routing the packet to one of the plurality of VNFs based at least in part on the context, the identified first VNF, and a target routing distribution of the plurality of VNFs.

[0112] Example 22. The method of claim 21, wherein the one VNF is the first VNF.

[0113] Example 23. The method of claim 21, comprising maximizing compliance with the target routing distribution and minimizing routing the packet to the one of the plurality of VNFs that is different from the first VNF.

[0114] Example 24. The method of claim 21 , comprising hashing the at least one field from the packet to determine the context.

[0115] Example 25. The method according to claim 24 includes: determining a hash bucket corresponding to the determined context based on the calculated hash function; counting the number of times the packet has been routed to the hash bucket; and selecting the one of the multiple VNFs to route the packet to it based at least in part on the determined hash bucket and the number of times the packet has been routed to the hash bucket.

[0116] Example 26. The method of claim 25, comprising determining the hash bucket based on the target routing distribution.

[0117] Example 27. The method of claim 21, comprising limiting routing of the packet to the one of the plurality of VNFs that is different from the first VNF ​​based on a threshold context switch limit.

[0118] Example 28. The method of claim 21, comprising: determining whether one of the multiple VNFs is associated with the context based on a routing table; and identifying the first VNF ​​as the one of the multiple VNFs based on determining that the one of the multiple VNFs is associated with the context.

[0119] Example 29. The method of claim 21, comprising: routing the packet to a second VNF among the multiple VNFs in parallel with routing the packet to the one VNF among the multiple VNFs based at least in part on the context, the identified first VNF, and the target routing distribution of the multiple VNFs.

[0120] Example 30. An apparatus comprising means for performing the method as described in any one of claims 21 to 29.

[0121] Example 31. A computer-readable storage medium storing instructions for execution by a network virtualization function (NFV) load balancing switch, the instructions being used to cause the NFV load balancing switch to: extract at least one field from a packet; determine a context associated with the packet based on the at least one field; identify a first virtual network function (VNF) among a plurality of VNFs that is associated with the determined context; and route the packet to one of the plurality of VNFs based at least in part on the context, the identified first VNF, and a target routing distribution of the plurality of VNFs.

[0122] Example 32. The computer-readable storage medium of claim 31 , wherein the one VNF is a first VNF.

[0123] Example 33. The computer-readable storage medium of claim 31, comprising instructions for causing the NFV load balancing switch to maximize compliance with the target routing distribution and minimize routing the packet to a VNF of the plurality of VNFs that is different from the first VNF.

[0124] Example 34. The computer-readable storage medium of claim 31 , comprising instructions for causing the NFV load balancing switch to hash the at least one field from the packet to determine the context.

[0125] Example 35. The computer-readable storage medium of claim 34, comprising instructions for causing the NFV load balancing switch to: determine a hash bucket corresponding to the determined context based on the calculated hash function; count the number of times the packet has been routed to the hash bucket; and select the one of the multiple VNFs to route the packet based at least in part on the determined hash bucket and the number of times the packet has been routed to the hash bucket.

[0126] Example 36. The computer-readable storage medium of claim 35, comprising instructions for causing the NFV load balancing switch to determine the hash bucket based on the target route distribution.

[0127] Example 37. The computer-readable storage medium of claim 31, comprising instructions for causing the NFV load balancing switch to limit routing of the packet to the one of the plurality of VNFs that is different from the first VNF ​​based on a threshold context switch limit.

[0128] Example 38. A computer-readable storage medium according to claim 31, comprising instructions for causing the NFV load balancing switch to perform the following operations: determining whether one of the multiple VNFs is associated with the context based on a routing table; and identifying the first VNF ​​as the one of the multiple VNFs based on determining that the one of the multiple VNFs is associated with the context.

[0129] Example 39. A computer-readable storage medium according to claim 31, comprising instructions for causing the NFV load balancing switch to perform the following operations: routing the packet to a second VNF among the multiple VNFs in parallel with routing the packet to the one VNF among the multiple VNFs based at least in part on the context, the identified first VNF, and the target routing distribution of the multiple VNFs.

[0130] It should be noted that the methods described herein do not have to be executed in the order described or in any particular order. In addition, various activities described with respect to the methods identified herein can be executed in serial or parallel manner.

[0131] Although specific embodiments have been illustrated and described herein, it should be appreciated that any arrangement calculated to achieve the same purpose may replace the specific embodiments shown. The present disclosure is intended to cover any and all modifications or variations of the various embodiments. It should be understood that the above description is provided in an illustrative manner and not restrictive. Combinations of the above-described embodiments and other embodiments not specifically described herein will be apparent to those skilled in the art after reading the above description. Therefore, the scope of the various embodiments includes any other application in which the above-described compositions, structures, and methods are used.

[0132] It is emphasized that the abstract of the present disclosure is provided to comply with 37 CFR Section 1.72 (b), requiring that the abstract allow the reader to quickly determine the essence of the technical disclosure. It should be understood that the abstract is not used to interpret or limit the scope or meaning of the claims. In addition, in the previous detailed description, it can be seen that various features are grouped together in a single embodiment for the purpose of simplifying the present disclosure. This method of disclosure should not be interpreted as reflecting the intention that the claimed embodiments require more features than those explicitly stated in each claim. On the contrary, as reflected in the following claims, the subject matter of the present invention lies in less than all the features of the disclosed examples. Therefore, the following claims are incorporated into the specific implementation mode, wherein each claim is independently used as a separate preferred example. In the appended claims, the terms "including" and "in which" are used as the plain English equivalents of the respective terms "comprising" and "wherein", respectively. In addition, the terms "first", "second", "third", etc. are used only as labels and are not intended to impose numerical requirements on their objects.

[0133] Although the subject matter has been described in language specific to structural features and / or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

1. A device for managing a virtual network function, comprising: A load balancing circuit, at least a portion of which is implemented in hardware, the circuit being configured to: Extract at least one field from the grouping; Determining a context associated with the packet based on the at least one field, the context being used to associate the packet with at least one VNF of a plurality of virtual network functions (VNFs); identifying, based on the context, a first VNF ​​among the plurality of VNFs that is associated with the packet; as well as The packet is routed to a VNF among the plurality of VNFs based at least in part on the context, the identified first VNF, and a target routing distribution for the plurality of VNFs.

2. The device according to claim 1, wherein: The one VNF among the plurality of VNFs is the first VNF, and the circuit is configured to: determining, based on at least one field of the second packet, that the context of the second packet is undefined; Defining a context of the second packet in a routing table, the context of the second packet being used to associate a second VNF among the plurality of VNFs with the second packet; as well as The second packet is routed to the second VNF among the multiple VNFs based on the defined context of the second packet and the target routing distribution for the multiple VNFs.

3. An apparatus according to claim 1, wherein the circuit is used to maximize the compliance of the routing of the packet with the target routing distribution and minimize the routing of the packet to the second VNF based on the context of not associating the packet with a second VNF among the multiple VNFs that is different from the first VNF. 4 . The apparatus of claim 1 , said circuitry to compute a hash value based on the at least one field from the packet to determine the context.

5. The apparatus according to claim 4, wherein the circuit is configured to: determining a first hash bucket of a plurality of hash buckets corresponding to the calculated hash value; determining a number of times a packet has been routed through the first hash bucket; and The one of the plurality of VNFs is selected to route the packet thereto based at least in part on the first hash bucket and the number of times the packet has been routed through the first hash bucket.

6. The apparatus of claim 5, wherein the circuit is configured to determine the first hash bucket based on the target route distribution for the plurality of VNFs, the first hash bucket being associated with the context.

7. The device according to claim 1, wherein: The one VNF of the plurality of VNFs is a second VNF of the plurality of VNFs, and the circuit is configured to: Switching the context of the packet from the first VNF ​​to the second VNF; determining a number of context switches based on moving the context of the packet from the first VNF ​​to the second VNF; as well as Routing the packet to a third VNF among the multiple VNFs is limited based on a threshold number of context switches and the number of context switches.

8. The device according to claim 1, wherein: The one VNF among the multiple VNFs is a second VNF among the multiple VNFs, and the context is used to associate the packet with the second VNF.

9. The apparatus of claim 1, wherein the circuit is configured to: determining, based on a routing table, that the first VNF ​​is associated with the packet, the routing table storing a plurality of contexts including the context; and Determine based on the routing table that the first VNF ​​is associated with the group, and thereby identify the first VNF ​​as the one of the multiple VNFs based on the determination.

10. An apparatus as described in claim 1, wherein the circuit is used to route the packet to a second VNF among the multiple VNFs in parallel with routing the packet to the one VNF among the multiple VNFs based at least in part on: a context associating the packet with the second VNF, the identified first VNF, and a target routing distribution for the multiple VNFs.

11. A system for managing a virtual network function, comprising: Multiple virtual network functions VNFs hosted on one or more logical servers; a memory comprising a Network Function Virtualization (NFV) database (DB) coupled to the one or more logical servers, the NFV DB comprising an indication of contexts associated with the plurality of VNFs; as well as A NFV load balancer comprising circuitry, at least a portion of which is implemented in hardware, for: Extract at least one field from the grouping; determining a context associated with the packet based on the at least one field, the context being used to associate the packet with at least one VNF of a plurality of VNFs; identifying, based on the context, a first VNF ​​among the plurality of VNFs that is associated with the packet; as well as The packet is routed to a VNF among the plurality of VNFs based at least in part on the context, the identified first VNF, and a target routing distribution for the plurality of VNFs.

12. The system according to claim 11, wherein: The one VNF among the multiple VNFs is the first VNF.

13. A system according to claim 11, wherein the circuit is used to maximize the compliance of the routing of the packet with the target routing distribution and minimize the routing of the packet to the second VNF based on not associating the packet with the context of the second VNF in the multiple VNFs that is different from the first VNF.

14. The system of claim 11, said circuitry to compute a hash value based on the at least one field from the packet to determine the context.

15. The system of claim 14, wherein the circuit is configured to: determining a first hash bucket of a plurality of hash buckets corresponding to the calculated hash value; determining a number of times a packet has been routed through the first hash bucket; and The one of the plurality of VNFs is selected to route the packet thereto based at least in part on the first hash bucket and the number of times the packet has been routed through the first hash bucket.

16. The system of claim 15, the circuitry being configured to determine the first hash bucket based on the target route distribution for the plurality of VNFs, the first hash bucket being associated with the context.

17. The system of claim 11, wherein the circuit is configured to: determining, based on a routing table, that the first VNF ​​is associated with the packet, the routing table storing a plurality of contexts including the context; and Determine based on the routing table that the first VNF ​​is associated with the group, and thereby identify the first VNF ​​as the one of the multiple VNFs based on the determination.

18. A system according to claim 11, wherein the circuit is used to route the packet to a second VNF among the multiple VNFs in parallel with routing the packet to the one VNF among the multiple VNFs based at least in part on: a context associating the packet with the second VNF, the identified first VNF, and a target routing distribution for the multiple VNFs.

19. A method for managing a virtual network function, comprising: Extract at least one field from the grouping; Determining a context associated with the packet based on the at least one field, the context being used to associate the packet with at least one VNF of a plurality of virtual network functions (VNFs); identifying, based on the context, a first VNF ​​among the plurality of VNFs that is associated with the packet; as well as The packet is routed to a VNF among the plurality of VNFs based at least in part on the context, the identified first VNF, and a target routing distribution for the plurality of VNFs.

20. The method according to claim 19, wherein: The one VNF among the multiple VNFs is the first VNF.

21. The method of claim 19, comprising maximizing the compliance of the routing of the packet with the target routing distribution and minimizing routing the packet to the second VNF among the multiple VNFs that is different from the first VNF ​​based on the context not associating the packet with the second VNF.

22. The method of claim 19, comprising hashing the at least one field from the packet to determine the context.

23. The method of claim 22, comprising: determining a first hash bucket of a plurality of hash buckets corresponding to the hashed at least one field; determining a number of times a packet has been routed through the first hash bucket; as well as The one of the plurality of VNFs is selected to route the packet thereto based at least in part on the first hash bucket and the number of times the packet has been routed through the first hash bucket.

24. The method according to claim 19, comprising: determining, based on a routing table, that the first VNF ​​is associated with the packet, the routing table storing a plurality of contexts including the context; as well as Determine based on the routing table that the first VNF ​​is associated with the group, and thereby identify the first VNF ​​as the one of the multiple VNFs based on the determination.

25. The method of claim 19, comprising routing the packet to a second VNF among the multiple VNFs in parallel with routing the packet to the one VNF among the multiple VNFs based at least in part on: a context associating the packet with the second VNF, the identified first VNF, and a target routing distribution for the multiple VNFs.

Images