FUNCTION

CROSS-REFERENCE TO RELATED APPLICATION

[0001] This application is related to and claims priority under 35 U.S.C. § 119(e) from U.S.

Patent Application No. 63/382,975, filed November 9, 2022, titled “ENHANCED TESTING OF EDGE GATEWAYS WITH A VIRTUAL NETWORK FUNCTION,” the entire content of which is incorporated herein by reference for all purposes.

TECHNICAL FIELD

[0002] Embodiments of the present invention generally relate to systems and methods for testing edge gateways with a virtual network function.

BACKGROUND

[0003] Network customers may test virtual machine functionality with edge gateways for compatibility with network edge gateways. Testing often requires the edge gateway hardware to be configured at a customer premise, and testing may require weeks or months.

SUMMARY

[0004] A method for remotely testing virtual network functions with edge gateway devices may include providing, by at least one processor, an application associated with receiving user inputs for testing a virtual network function (VNF) with an edge gateway device remote from the VNF; receiving, by the at least one processor, via the application, a first user input associated with adding an image of a virtual machine instance to the application; downloading, by the at least one processor, via the application, the image based on the first user input; receiving, by the at least one processor, via the application, a second user input associated with instantiating a service associated with the virtual machine instance; instantiating, by the at least one processor, via the application, the service based on the second user input; receiving, by the at least one processor, via the application, a third user input associated with testing the VNF with the edge gateway device using the image and the service; and executing, by the at least one processor, via the application, a test of the VNF with the edge gateway device using the image and the service based on the third user input.

[0005] A system for remotely testing virtual network functions with edge gateway devices may include memory coupled to at least one processor, the at least one processor configured to: provide an application associated with receiving user inputs for testing a virtual network function (VNF) with an edge gateway device remote from the VNF; receive, via the application, a first user input associated with adding an image of a virtual machine instance to the application; download, via the application, the image based on the first user input; receive, via the application, a second user input associated with instantiating a service associated with the virtual machine instance; instantiate, via the application, the service based on the second user input; receive, via the application, a third user input associated with testing the VNF with the edge gateway device using the image and the service; and execute, via the application, a test of the VNF with the edge gateway device using the image and the service based on the third user input.

[0006] A non-transitory computer-readable storage medium may include instructions to cause at least one processor for remotely testing virtual network functions with edge gateway devices, upon execution of the instructions by the at least one processor, to: provide an application associated with receiving user inputs for testing a virtual network function (VNF) with an edge gateway device remote from the VNF; receive, via the application, a first user input associated with adding an image of a virtual machine instance to the application; download, via the application, the image based on the first user input; receive, via the application, a second user input associated with instantiating a service associated with the virtual machine instance; instantiate, via the application, the service based on the second user input; receive, via the application, a third user input associated with testing the VNF with the edge gateway device using the image and the service; and execute, via the application, a test of the VNF with the edge gateway device using the image and the service based on the third user input.

BRIEF DESCRIPTION OF THE DRAWINGS

[0007] FIG. 1 illustrates an example system for testing virtual network functions with edge gateway devices, in accordance with one embodiment. [0008] FIG. 2 shows an example dashboard interface of a system for testing virtual network functions with edge gateway devices, in accordance with one embodiment.

[0009] FIG. 3 shows an example services interface of a system for testing virtual network functions with edge gateway devices, in accordance with one embodiment.

[0010] FIG. 4 shows an example test interface of a system for testing virtual network functions with edge gateway devices, in accordance with one embodiment.

[0011] FIG. 5 shows an example jobs interface of a system for testing virtual network functions with edge gateway devices, in accordance with one embodiment.

[0012] FIG. 6 is a flow for a process for testing virtual network functions with edge gateway devices, in accordance with one embodiment.

[0013] FIG. 7 is a diagram illustrating an example of a computing system that may be used in implementing embodiments of the present disclosure.

DETAILED DESCRIPTION

[0014] Aspects of the present disclosure involve systems, methods, and the like, for enhanced testing of edge gateways with a virtual network function.

[0015] Some communications network customers may want to test their virtual network functionality with an edge gateway of a communications network (e.g., to determine whether an edge gateway is a solution for the customer’s virtual network function). Tests currently require sending all this hardware to a customer premise. To test a virtual network function (VNF), hardware often is sent to a customer so they can test it with the VNF, often requiring significant field testing over weeks or months.

[0016] There is therefore a need for enhanced testing of edge gateways with a virtual network function.

[0017] In one or more embodiments, an application may enable a communications network user to test a VNF with an edge gateway of the communications network without requiring the edge gateway hardware to be built and configured at the customer premise. An application may allow the customer to add an image to use for virtual machine instances (e.g., a virtual machine image that behaves like a computer). The application may allow users to run manual tests, automated tests, schedule tests, manage images (e.g., for virtual machine instances) loaded to the edge gateway, view test metrics, and manage users that have access to the application test portal. The application may function as a software “sandbox” that allows users to test their machine image/environment without any new hardware required to be installed.

[0018] In one or more embodiments, the application may allow users to upload an image of their virtual machine. The application will facilitate service instantiation using the virtual machine image, create logical connections for the VNF on physical hardware, and perform tests, including customer-defined tests.

[0019] In one or more embodiments, the application provides a premise virtualization concept that allows users to “try before buying” by not requiring the edge gateway hardware to be purchased prior to testing VNFs with the edge gateways. The application allows users to upload a virtual machine image and reserve available hardware racks for testing. Instantiating a service may include application programming interface (API) calls to software that creates procedures to communicate with the testing environment. The application may facilitate spinning up the VNF, creating and testing the gateway, and the like without the user’s involvement. The physical devices and their connections used in the testing may be set up (e.g., in a lab remote from customer premises), and the logical connections may be established by the application based on the user’s selected inputs. The establishment of the connections may be automated in this manner. The tests may be templatized, and testing may be scheduled periodically (e.g., allowing for repetition), including the reservation of an environment and performance of the tests at different days, times, etc.

[0020] In one or more embodiments, the application may store only one copy of a machine image at a time, but users may use an image as many times as needed for separate virtual machine instances. The application may use checksums to verify images (e.g., checksums are unique identifiers assigned to images). To add an image, a user may sign into the application, select “add image,” and complete corresponding fields such as image name, uniform resource locator (URL), checksum type (e.g., MD5, etc.), host type (e.g., type of edge gateway), required CPU count, required RAM, required disk memory, and the like. Table 1 below shows example fields and their descriptions for adding an image. Table 1: Fields for Adding an Image:

[0021] In one or more embodiments, after the user has entered the fields to add an image with the application, the user may select “start download” to cause the application to add the image based on the entered data from Table 1.

[0022] In one or more embodiments, the application may enable users to create services that represent their virtual machine configuration. Services may have multiple instances using the same image multiple times, or different images for each instance. Services may be configured as one of the following VNF type combinations: one router, one router and any of a bring your own firewall, one sessions border controller, one monitor, or one bring your own IT payload, and/or multiple bring your own IT payload. The create a service, the user may sign into the application, select “services,” select “instantiate service,” and in the instantiate services window of the application, may enter a name for the service and a description of the service. The user may select “add,” and in the instantiate services window, may complete the fields shown below in Table 2.

Table 2: Fields for Instantiating a Service: [0023] After entering the fields of Table 2, a user may select “save task,” and optionally may add instances as service components before instantiating the service. Selecting “instantiate” will result in the application creating the service and displaying the progress in a running job window.

[0024] In one or more embodiments, the application may allow users to test functionality and correct configurations by retrieving instance console URLs and running tests. A user may use the application to run tests with parameters using a parser. The application may evaluate test results (e.g., with XPath, JSON path, or REGEX parser types and expressions).

[0025] In one or more embodiments, the application may retrieve console URLs. To retrieve an instance console URL, a user may sign into the application, select “services,” enter a name or keywords into a search field to filter services presented, and select the desired service from the corresponding list of presented services. The user may select “run test” on the selected service, and complete the fields of Table 3 below in a “run test” window.

Table 3: Fields to Run Test:

[0026] Optionally, to add success parameters to the test to ensure that the virtual machine is working as intended, the user may select “add evaluations” and complete the fields of Table 4 below. Table 4: Fields to Add Evaluations:

[0027] Optionally, to add a job name and identifier o the test to simplify locating the test, the user may select “advanced options” and complete the fields of Table 5 below.

Table 5: Advanced Options for Tests:

[0028] Then, the user may select “run test” based on the user inputs. The application may display progress of the test as it runs, and once the test has completed, may indicate whether the test passes or fails.

[0029] In one or more embodiments, the user may select “services,” select the service that was tested, and select the instance that was tested. The user may select “tests,” and select the test that was run. The application may display the test details. From the test details presentation, the user may copy the consoleURL from the outputs, paste the consoleURL into a browser tab address bar, and navigate to the instance console where the user may test the instance console and view details.

[0030] In one or more embodiments, the application enables users to perform a hypertext transfer protocol (HTTP) request test on a service. The user may need the following information to perform the test: virtual machine IP address, URL, body, and headers. To perform an HTTP request test on a service, the user may sign into the application, select “services,” enter a name or keyword into the search field o filter presented services, and select desired service from the presented services to expand the information presented. The user may select “run test” on the desired service, and the application may present a “run test” window. In the “run test” window, the user may complete the fields of Table 6 below.

Table 6: Fields for Running a Test:

[0031] Optionally, to add success parameters to a test to ensure that a virtual machine is working as intended, the user may select “add evaluations” and complete the fields of Table 7 below.

Table 7: Fields for Adding Evaluations:

[0032] Optionally, to add a job name and identifier to the test to simplify locating the test, the user may select “advanced options” and complete the fields of Table 8 below. Table 8. Fields to Add Evaluations:

[0033] The user may select “run test,” the application may run the test, and may display the progress of the test. When the test passes or fails, the application may display an indication of passage or failure accordingly. On a services page, the user may select the service tested, and select the instance tested. On a tests tab, the user may select the task that was run. The application may display the test details, and in the test details, the user may view the test results in an outputs section. The output information and test URLs may be used by the user as needed.

[0034] In one or more embodiments, he application may allow a user to perform a Netconf test (e.g., protocol to install, manipulate, and delete network device configurations) on a service, and may require the following information to perform the test: port, username, password, and template. The user may sign into the application, select “services,” select a desired service, select “run test” on the selected service, and the application may run the test on the service. The user may enter the fields of Table 9 below.

Table 9: Fields for Running a Test:

[0035] Optionally, the user may add success parameters to the test to ensure that the virtual machine is working as intended. The user may select “add evaluations” and complete the fields of Table 10 below:

Table 10: Fields to Add Evaluations:

[0036] Optionally, the user may add a job name and identifier to the test to simplify locating the test, the user may select “advanced options” and complete the fields shown below in Table 11. Table 11: Advanced Options:

[0037] The user may select “run test,” the application may run the test and present the progress of the test, and when complete, may present results of the test (e.g., passage or failure). On the services tab, the user may select the service tested, the instance tested, and the test that was run. The application may display the test details.

[0038] In one or more embodiments, the application may allow users to perform an Ansible test on a service when the user provides the virtual machine’s IP address, port, their username and password, and playbook (e.g., list of tasks that automatically execute for specified inventory/groups). Table 12 below shows the inputs used for running an Ansible test with the application. Other tests may be selected and run, such as Netconf and HTTP request tests, for example.

Table 12: Fields for Running Ansible Test:

[0039] Optionally, a user may add success parameters to the Ansible test to ensure that the virtual machine is operating as intended. The success parameters may be added when the user selects “add evaluations” with the application according to the fields of Table 13 below.

Table 13: Fields for Adding Evaluations to Ansible Test:

[0040] Optionally, a user may select Advanced Options to add a job identifier to the Ansible test according to the fields of Table 14 below. Table 14: Advanced Fields for Ansible Test:

[0041] When a user selects “Run Test,” the application may run the Ansible test according to the inputs provided by the user, and may present the progress and results of the test.

[0042] In one or more embodiments, the application may allow users to delete a service or instance from the application. If an instance in a service is deleted and that is the only instance in the service, the service may be deleted.

[0043] In one or more embodiments, the application may allow users to manage images used for virtual machines. The application may enable users to authorize images to indicate that they have been tested and approved once the image has been added via the application. The application may allow users to view details of downloaded images, such as status of authorization, source location, specifications, and checksums. The application may allow users to delete images from the application. The application may allow users to edit image names. The application may allow users to download images for virtual machines and store the images locally. The application may allow users to view jobs such as downloading an image to use for an instance and instantiating a service. The application may present details of a job, such as start and end times, state (e.g., complete, failed, etc.), and activity logs (e.g., debug, information, warning, error).

[0044] In one or more embodiments, the application may allow users to create job templates. Job templates may refer to preconfigured parameters for jobs that can be performed immediately or at scheduled times. For example, a user may create a job template to perform Ansible tests on specified machines on a bi-weekly basis. Table 15 below shows the fields used for user inputs for building a job template.

Table 15: Job Type Fields:

[0045] In one or more embodiments, the application may allow users to start a job from a job template (e.g., to ensure uniform processing). To start a job from a job template, a user may complete the fields of Table 16 below.

Table 16: Fields for Starting a Job from a Job Template:

[0046] The above descriptions are for purposes of illustration and are not meant to be limiting.

Numerous other examples, configurations, processes, etc., may exist, some of which are described in greater detail below. Example embodiments will now be described with reference to the accompanying figures. [0047] FIG. 1 illustrates an example system 100 for testing virtual network functions with edge gateway devices, in accordance with one embodiment.

[0048] Referring to FIG. 1, the system 100 may include customer premise devices 102 (e.g., customer premise device 104, customer premise device 106, etc.) including VNFs (e.g., the customer premise device 104 including a VNF 108 and the customer premise device 106 including a VNF 110) that may be tested with host devices 112 (e.g., edge gateway devices) using an application represented by VNF testing modules 114 provided by a remote service 116. The host devices 112 may be physically and logically arranged and configured at a location remote from the customer premise devices 102 such that the VNF 108 and the VNF 110 may be tested on the host devices 112 without the host devices 112 being physically present at the customer premises.

[0049] In one or more embodiments, the VNF testing modules 114 may allow the customer premise devices 102 to provide user inputs to add virtual machine images, instantiate services associated with instances of the virtual machine images, test the VNFs with the host devices 112, and the like. Tables 1-16 above show example fields that the VNF testing modules 114 may provide via one or more user interfaces, and that may be entered by the customer premise devices 102.

[0050] In one or more embodiments, the application represented by the VNF modules 114 may enable a communications network user to test a VNF with an edge gateway (e.g., the host devices 112) without requiring the edge gateway hardware to be built and configured at the customer premise. The application may allow a customer to add an image to use for virtual machine instances. The application may allow users to run manual tests, automated tests, schedule tests, manage images (e.g., for virtual machine instances) loaded to the edge gateway, view test metrics, and manage users that have access to the application test portal. The application may function as a software “sandbox” that allows users to test their machine image/environment without any new hardware required to be installed.

[0051] In one or more embodiments, the application represented by the VNF modules 114 may allow users to upload an image of their virtual machine. The application will facilitate service instantiation using the virtual machine image, create logical connections for the VNF on physical hardware, and perform tests, including customer-defined tests. [0052] In one or more embodiments, the application represented by the VNF modules 114 provides a premise virtualization concept that allows users to “try before buying” by not requiring the edge gateway hardware of the host devices 112 to be purchased prior to testing VNFs with the edge gateways. The application allows users to upload a virtual machine image and reserve available hardware racks for testing. Instantiating a service may include API calls to software that creates procedures to communicate with the testing environment where the host devices 112 are located. The application may facilitate spinning up the VNF, creating and testing the gateway, and the like without the user’s involvement. The physical devices and their connections used in the testing may be set up (e.g., in a lab remote from customer premises), and the logical connections may be established by the application based on the user’s selected inputs. The establishment of the connections may be automated in this manner. The tests may be templatized, and testing may be scheduled periodically (e.g., allowing for repetition), including the reservation of an environment and performance of the tests at different days, times, etc.

[0053] FIG. 2 shows an example dashboard interface 200 of a system for testing virtual network functions with edge gateway devices, in accordance with one embodiment.

[0054] Referring to FIG. 2, the dashboard interface 200 may be presented by a device 202 using the VNF testing modules 114 of FIG. 1 to allow users to see, add, edit, and remove virtual machine instance images, their state, and their dates. Table 1 above shows fields that a user may input when requesting to add a virtual machine instance image, such as a name 210 for the image, an address (e.g., a URL), state 212 (e.g., authorized, complete, failed, etc.), date 214, the checksum and checksum type, the type of host device (e.g., of the host devices 112 of FIG. 1), and the computer resources needed (e.g., CPU, memory, etc.). A selectable option to add a virtual machine image 216 also may be presented using the dashboard interface 200. The user also may create and name a job for adding an image. Once the user inputs have been provided for adding an image, the VNF testing modules 114 may download the image from the input address, and may add the image based on the configuration specified by the user inputs.

[0055] FIG. 3 shows an example services interface 300 of a system for testing virtual network functions with edge gateway devices, in accordance with one embodiment.

[0056] Referring to FIG. 3, the services interface 300 may be presented using the VNF testing modules 114 of FIG. 1 and the device 202 to allow users to create services that represent a virtual machine configuration. Services can have multiple instances using the same image multiple times or different images for each instance. As shown in FIG. 3, the services interface 300 may show the status 302 of services, their names 304, descriptions 306, and where they have been instantiated 308. When a user requests to instantiate a service (e.g., using a selectable option to instantiate a service 310) from the services interface 300, the user may be prompted to input a service name and description, along with other fields as shown in Table 2 above. The VNF testing modules 114 may create the service based on the user inputs.

[0057] FIG. 4 shows an example test interface 400 of a system for testing virtual network functions with edge gateway devices, in accordance with one embodiment.

[0058] Referring to FIG. 4, the test interface 400 may be presented using the VNF testing modules 114 of FIG. 1 and the device 202 to allow users to create and execute tests of VNFs with host devices, and to see the progress and result of the tests. For example, as shown in FIG.

4, the test interface 400 may present the status 302 of a test (e.g., empty 402, online 404, deleted 405), an instance type 406 being tested by a test, an instance name 408, a test environment 410, and where the test is instantiated 308. When a user requests to run a test (e.g., using a selectable option 412), the user may be prompted to provide inputs as shown in Table 3 above, optionally in Table 4 above to add success parameters, and optionally in Table 5 above to add a job name and identifier for running a test. A user may select to authorize virtual machine images assigned to a service after a successful test or to leave images unauthorized even after a successful test. Tests may include HTTP tests, Netconf tests, and Ansible tests, for some examples.

[0059] FIG. 5 shows an example jobs interface 500 of a system for testing virtual network functions with edge gateway devices, in accordance with one embodiment.

[0060] Referring to FIG. 5, the jobs interface 500 may be presented using the VNF testing modules 114 of FIG. 1 to allow users to view job details and logs. For example, jobs may include actions such as downloading an image to use for an instance and instantiating a service.

If errors occur when downloading an image or instantiating a service, for example, the job details or logs may indicate what caused the error. The jobs interface 500 may show a job name, a job state (e.g., complete, failed, in progress, etc.), and job start and end times. Job logs may show debug items, information items, warning items, and error items, for example. From the jobs interface 500, a user may start a job, which may or may not be defined by a template, and to create a job template define a job and when to perform the job. The fields in Table 15 above show the user inputs that a user may be prompted to provide upon creating a job. Table 16 above shows the fields that a user may be prompted to provide upon creating a job template.

[0061] FIG. 6 is a flow for a process 600 for testing virtual network functions with edge gateway devices, in accordance with one embodiment.

[0062] At block 602, a device (e.g., the remote service 116) may provide an application (e.g., represented by the VNF testing modules 114 of FIG. 1) associated with receiving user inputs for testing a VNF function (e.g., the VNF 108 of FIG. 1) with an edge gateway device (e.g., the host devices 112) remote from the VNF (e.g., in a testing environment remote from the customer premises where the VNF resides).

[0063] At block 604, the device may receive, via the application (e.g., the dashboard interface 200 of FIG. 2), a first user input associated with adding an image of a virtual machine to the application. Table 1 above shows fields that a user may input when requesting to add a virtual machine instance image, such as a name for the image, an address (e.g., a URL), the checksum and checksum type, the type of host device (e.g., of the host devices 112 of FIG. 1), and the computer resources needed (e.g., CPU, memory, etc.). The user also may create and name a job for adding an image.

[0064] At block 606, the device may download, via the application, the image based on the first user input. In particular, the user may provide an address (e.g., URL) when inputting the first user input, the address representing a location from which the device may download the image.

[0065] At block 608, the device may receive, via the application (e.g., the services interface 300 of FIG. 3), a second user input associated with instantiating a service associated with the virtual machine instance. When a user requests to instantiate a service from the services interface 300, the user may be prompted to input a service name and description, along with other fields as shown in Table 2 above.

[0066] At block 610, the device may instantiate, via the application, based on the second user input, the service. Instantiation may depend on the selected instance, edge gateway environment for instantiation, script, VNF type, and image provided by the user via the application. [0067] At block 612, the device may receive, via the application (e.g., the test interface 400 of FIG. 4), a third user input associated with testing the VNF with the edge gateway device using the image and the service inputted by the user. When a user requests to run a test, the user may be prompted to provide inputs as shown in Table 3 above, optionally in Table 4 above to add success parameters, and optionally in Table 5 above to add a job name and identifier for running a test. A user may select to authorize virtual machine images assigned to a service after a successful test or to leave images unauthorized even after a successful test. Tests may include HTTP tests, Netconf tests, and Ansible tests, for some examples.

[0068] At block 614, the device may execute, via the application, the test of the VNF with the edge gateway device using the user-provided image and selected service based on the third user input. When executing a test, the selected edge gateway device may be configured according to the user inputs and virtual machine configuration without the selected edge gateway device needing to be at the customer premises. In this manner, the VNF test may be run remotely.

[0069] It is understood that the above descriptions are for purposes of illustration and are not meant to be limiting.

[0070] FIG. 7 is a block diagram illustrating an example of a computing device or computer system 700 which may be used in implementing the embodiments of the components of the network disclosed above. For example, the computing system 700 of FIG. 7 may represent at least a portion of the system 100 shown in FIG. 1, as discussed above. The computer system (system) includes one or more processors 702-706, the VNF testing modules 114 of FIG. 1, and a hypervisor 711 for facilitating VNFs. Processors 702-706 may include one or more internal levels of cache (not shown) and a bus controller 722 or bus interface unit to direct interaction with the processor bus 712. Processor bus 712, also known as the host bus or the front side bus, may be used to couple the processors 702-706 with the system interface 724. System interface 724 may be connected to the processor bus 712 to interface other components of the system 700 with the processor bus 712. For example, system interface 724 may include a memory controller 718 for interfacing a main memory 716 with the processor bus 712. The main memory 716 typically includes one or more memory cards and a control circuit (not shown). System interface 724 may also include an input/output (I/O) interface 720 to interface one or more VO bridges 725 or I/O devices with the processor bus 712. One or more I/O controllers and/or I/O devices may be connected with the I/O bus 726, such as I/O controller 728 and I/O device 730, as illustrated.

[0071] I/O device 730 may also include an input device (not shown), such as an alphanumeric input device, including alphanumeric and other keys for communicating information and/or command selections to the processors 702-706. Another type of user input device includes cursor control, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to the processors 702-706 and for controlling cursor movement on the display device.

[0072] System 700 may include a dynamic storage device, referred to as main memory 716, or a random access memory (RAM) or other computer-readable devices coupled to the processor bus 712 for storing information and instructions to be executed by the processors 702-706. Main memory 716 also may be used for storing temporary variables or other intermediate information during execution of instructions by the processors 702-706. System 700 may include a read only memory (ROM) and/or other static storage device coupled to the processor bus 712 for storing static information and instructions for the processors 702-706. The system outlined in FIG. 7 is but one possible example of a computer system that may employ or be configured in accordance with aspects of the present disclosure.

[0073] According to one embodiment, the above techniques may be performed by computer system 700 in response to processor 704 executing one or more sequences of one or more instructions contained in main memory 716. These instructions may be read into main memory 716 from another machine-readable medium, such as a storage device. Execution of the sequences of instructions contained in main memory 716 may cause processors 702-706 to perform the process steps described herein. In alternative embodiments, circuitry may be used in place of or in combination with the software instructions. Thus, embodiments of the present disclosure may include both hardware and software components.

[0074] A machine readable medium includes any mechanism for storing or transmitting information in a form (e.g., software, processing application) readable by a machine (e.g., a computer). Such media may take the form of, but is not limited to, non-volatile media and volatile media and may include removable data storage media, non-removable data storage media, and/or external storage devices made available via a wired or wireless network architecture with such computer program products, including one or more database management products, web server products, application server products, and/or other additional software components. Examples of removable data storage media include Compact Disc Read-Only Memory (CD-ROM), Digital Versatile Disc Read-Only Memory (DVD-ROM), magneto-optical disks, flash drives, and the like. Examples of non-removable data storage media include internal magnetic hard disks, SSDs, and the like. The one or more memory devices 706 may include volatile memory (e.g., dynamic random access memory (DRAM), static random access memory (SRAM), etc.) and/or non-volatile memory (e.g., read-only memory (ROM), flash memory, etc.).

[0075] Computer program products containing mechanisms to effectuate the systems and methods in accordance with the presently described technology may reside in main memory 716, which may be referred to as machine-readable media. It will be appreciated that machine- readable media may include any tangible non-transitory medium that is capable of storing or encoding instructions to perform any one or more of the operations of the present disclosure for execution by a machine or that is capable of storing or encoding data structures and/or modules utilized by or associated with such instructions. Machine-readable media may include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more executable instructions or data structures.

[0076] Embodiments of the present disclosure include various steps, which are described in this specification. The steps may be performed by hardware components or may be embodied in machine-executable instructions, which may be used to cause a general-purpose or specialpurpose processor programmed with the instructions to perform the steps. Alternatively, the steps may be performed by a combination of hardware, software and/or firmware.

[0077] Various modifications and additions can be made to the exemplary embodiments discussed without departing from the scope of the present invention. For example, while the embodiments described above refer to particular features, the scope of this invention also includes embodiments having different combinations of features and embodiments that do not include all of the described features. Accordingly, the scope of the present invention is intended to embrace all such alternatives, modifications, and variations together with all equivalents thereof.