Patent Application
20160352578
The present invention relates generally to data communication networks and devices, and relates more particularly to monitoring and management in network functions virtualization networks (NFV) where a plurality of virtualize network functions (VNF) are chained together.
As the value and use of information continues to increase, individuals and businesses seek additional ways to process and store information. One option available to users is information handling systems. An information handling system generally processes, compiles, stores, and/or communicates information or data for business, personal, or other purposes thereby allowing users to take advantage of the value of the information. Because technology and information handling needs and requirements vary between different users or applications, information handling systems may also vary regarding what information is handled, how the information is handled, how much information is processed, stored, or communicated, and how quickly and efficiently the information may be processed, stored, or communicated. The variations in information handling systems allow for information handling systems to be general or configured for a specific user or specific use such as financial transaction processing, airline reservations, enterprise data storage, or global communications. In addition, information handling systems may include a variety of hardware and software components that may be configured to process, store, and communicate information and may include one or more computer systems, data storage systems, and networking systems.
As information handling systems provide increasingly more central and critical operations in modern society, it is important that the networks are reliable. One way to improve reliability is through monitoring and management of storage in networking systems.
Network Functions Virtualization (NFV) is a network architecture that uses Information Technology (IT) virtualization technologies to virtualize entire classes of network node functions into building blocks that can be connected, or chained, together to create communication services.
A service provider following the NFV design can implement one or more Virtualized Network Functions (VNFs) where multiple VNFs can be used in sequence to form a service chain to deliver a network service. Such a service chain can also contain one or multiple Physical Network Functions (PNFs) working in conjunction with the VNFs to provide end-to-end network services, which are usually referred to as virtual and physical function co-existence scenarios.
Service chaining scenarios in NFV is also referred to as VNF Forwarding Graphs. VNFs can be connected together in a ‘graph’ instead of a sequential ‘chain’ hence the VNF Forwarding Graph term can be used. For ease of explanation the following specification will use the terms service chaining and VNF Forwarding Graph interchangeably.
The network services provided by service chaining can run on redundant underlying virtual and physical network infrastructures. Network redundancy provides alternative paths for data to travel along in case a Virtual Machine (VM) is down, a network device is broken, or a connector accidentally un-plugged. Of course, there can be redundancy support on the network service level achieved by adding redundant VNFs or VNF level redundant paths for the robustness of the network service.
Furthermore, the network services with service chaining can run on network environment with or without Software Defined Networking (SDN). In a network environment without SDN, the physical network forwarding paths are configured statically. In a network environment with SDN, the physical network paths can be configured dynamically though the control plane resides centrally in the SDN controller.
From the architecture point of view, NFV systems contain three layers: Network Service Layer (NSL), Virtualized Infrastructure Layer (VIL), and Physical Network Layer (PNL). The VNF Forwarding Graph on Network Service Layer relies on the virtual resources including the VMs and network connectivity between the VMs on the virtualized infrastructure layer, which in turn relies on the physical resources including the computer, storage, and physical network connectivity provided on physical layer. Therefore, the network services in the upper layer have dependency on the virtualized infrastructure layer as well as the physical infrastructure layer.
All the complexity in NFV environment creates new opportunities, requirements and challenges in many perspectives of telecom industry. One challenge is the health monitoring of the network services with underlying redundant network topologies in service chaining scenarios. The monitoring of the network services with service chaining consists of the monitoring of the VNFs as well as the VNF Links. VNF links are the logical links on network service level that connects two adjacent VNFs together in a VNF Forwarding Graph. In virtual and physical co-existence scenarios, the links from the VNFs to the physical network functions (PNFs) or the links from the PNFs to VNFs also need to be monitored. This is called VNF_To_PNF_Links or PNF_To_VNF_Links, respectively.
Since VNFs contain both the virtual instances and the virtual links between them, the monitoring of the VNFs boils down to the monitoring of the virtual instances (VMs if the virtual container is virtual machines) and the virtual links between the VMs. The monitoring of the VNF Links, VNF_TO_PNF_Links, and PNF_To_VNF_Links boils down to the monitoring of the links between VMs and the links between VMs and the physical equipment. The monitoring of the VMs is relatively straight forward. There are tools in the related industry that provide the capability of monitoring the health of the VMs in the cloud. However, the monitoring of the links between the VMs or the links between the VMs and the physical equipment is complex and challenging. The health status of these links depends on both virtual and physical network connectivity provided from virtualized infrastructure and physical network layers respectively.
Accordingly, what is needed is to monitor the health of network service in service chaining embodiment with redundant underlying network topology. One important step to monitoring the health of the network service chaining embodiment includes monitoring the health status of the virtual links between VMs and the links between the VMs and the physical equipment.
Accordingly, what is needed is a system and method that can monitor across virtual and physical network paths associated with a VNF link in a VNF service changing embodiment.
Reference will be made to embodiments of the invention, examples of which may be illustrated in the accompanying figures, in which like parts may be referred to by like or similar numerals. These figures are intended to be illustrative, not limiting. Although the invention is generally described in the context of these embodiments, it should be understood that it is not intended to limit the spirit and scope of the invention to these particular embodiments. These drawings shall in no way limit any changes in form and detail that may be made to the invention by one skilled in the art without departing from the spirit and scope of the invention.
In the following description, for purposes of explanation, specific examples and details are set forth in order to provide an understanding of the invention. It will be apparent, however, to one skilled in the art that the invention may be practiced without these details. Well known process steps may not be described in detail in order to avoid unnecessarily obscuring the present invention. Other applications are possible, such that the following examples should not be taken as limiting. Furthermore, one skilled in the art will recognize that aspects of the present invention, described herein, may be implemented in a variety of ways, including software, hardware, firmware, or combinations thereof.
Components, or modules, shown in block diagrams are illustrative of exemplary embodiments of the invention and are meant to avoid obscuring the invention. It shall also be understood that throughout this discussion that components may be described as separate functional units, which may comprise sub-units, but those skilled in the art will recognize that various components, or portions thereof, may be divided into separate components or may be integrated together, including integrated within a single system or component. It should be noted that functions or operations discussed herein may be implemented as components or modules.
Furthermore, connections between components within the figures are not intended to be limited to direct connections. Rather, data between these components may be modified, re-formatted, or otherwise changed by intermediary components (which may or may not be shown in the figure). Also, additional or fewer connections may be used. It shall also be noted that the terms “coupled” or “communicatively coupled” shall be understood to include direct connections, indirect connections through one or more intermediary devices, and wireless connections.
In the detailed description provided herein, references are made to the accompanying figures, which form a part of the description and in which are shown, by way of illustration, specific embodiments of the present invention. Although these embodiments are described in sufficient detail to enable one skilled in the art to practice the invention, it shall be understood that these examples are not limiting, such that other embodiments may be used, and changes may be made without departing from the spirit and scope of the invention.
Reference in the specification to “one embodiment,” “preferred embodiment,” “an embodiment,” or “embodiments” means that a particular feature, structure, characteristic, or function described in connection with the embodiment is included in at least one embodiment of the invention and may be in more than one embodiment. Also, such phrases in various places in the specification are not necessarily all referring to the same embodiment or embodiments. It shall be noted that the use of the terms “set” and “group” in this patent document shall include any number of elements. Furthermore, it shall be noted that methods or algorithms steps may not be limited to the specific order set forth herein; rather, one skilled in the art shall recognize, in some embodiments, that more or fewer steps may be performed, that certain steps may optionally be performed, and that steps may be performed in different orders, including being done some steps being done concurrently.
The present invention relates in various embodiments to devices, systems, methods, and instructions stored on one or more non-transitory computer-readable media involving the communication of data over networks. Such devices, systems, methods, and instructions stored on one or more non-transitory computer-readable media can result in, among other advantages, the ability to monitor the health status of VNF network devices and paths in an NFV architecture.
It shall also be noted that although embodiments described herein may be within the context of management in a network device, the invention elements of the current patent document are not so limited. Accordingly, the invention elements may be applied or adapted for use in other contexts.
As shown in
In many cases, there exist multiple paths (some paths are represented in
From the monitoring point of view, if the monitoring tool can report the health status of VNFs, VNF links, VNF_To_PNF_Links, and PNF_To_VNF_Links, then the health status of network could be determined
Since VNFs contain both the virtual instances and the virtual links between them, the monitoring of the VNFs boils down to the monitoring of the virtual instances (VMs if the virtual container is virtual machines) and the virtual links between the VMs. The monitoring of the VNF Links, VNF_TO_PNF_Links, and PNF_To_VNF_Links boil down to the monitoring of the links between VMs and the links between VMs and the physical equipment. The monitoring of the VMs is relatively straight forward. There are tools in the related industry that provide the capability of monitoring the health of the VMs in the cloud. However, the monitoring of the links between the VMs or the links between the VMs and the physical equipment is complex and challenging. The health status of these links depends on both virtual and physical network connectivity provided from virtualized infrastructure and physical network layers respectively.
How to report the health status of a VNF link, VNF_To_PNF_Link, or PNF_to_VNF_Link based on the monitoring of multiple layers in NFV system becomes a problem in the NFV area, particularly when the system does not have the capability of discovering the physical topology with detailed path information.
What is needed is a path locator tool to understand the ‘Path’ concept and multiple Paths associated with two endpoints in the physical network system.
Embodiments of the present invention provide a VNF Link Paths Locator that reports the underlying network ‘Paths’ for a link on a VNF level. These embodiments can be used where NFV monitoring systems have the capability of monitoring the health status of various entities including both physical and virtual, such as switches, switch ports, hosts, physical network interface controllers (NICs) on the hosts, VMs, virtual NICs, etc. However, the NFV monitoring tool does not have the capability of discovering the physical links nor paths between two physical endpoints in a complex physical topology of the network.
Advantages of embodiments of the present invention is that it provides a component that is called VNF link paths locator, which has the capability of locating the virtual and physical paths associated with links between two VNFs or a VNF and a physical network endpoint in virtual and physical network function co-existence embodiments.
Using the example show in
Path1: (VM3140, VNIC3)→(Host1170, eth1)→(Access1185, 0/22)→(Aggregate1195, 0/8)→(Aggregate1195, 0/6)→(Access2190, 0/18)→(Host3180, eth2))→(VM6155, VNIC6)
Path2: (VM3140, VNIC3)→(Host1170, eth1)→(Access1185, 0/22)→(Aggregate2198, 0/6)→(Aggregate2198, 0/6)→(Access2190, 0/18)→(Host3180, eth2)→(VM6155, VNIC6)
Path3: (VM3140, VNIC3)→(Host1170, eth1)→(Access1185, 0/22)(Access1185, 0/18)→(Host3180, eth1)→(VM6155, VNIC6)
Path4: (VM3140, VNIC3)→(Host1170, eth2)→(Access2190, 0/22)→(Access2190, 0/18) (Host3180,eth2)→(VM6155, VNIC6)
If any one of the paths is up and running, the link between VNF-2 and VNF-4 will be healthy and connected.
If a request is sent to the VNF link paths locator with two endpoints, such as (VNF-2, VNF-4) in this example, the VNF link paths locator will reply with the result of the above four paths in a regular expression format, which is shown below:
(VM3, VNIC3) and (<host1IP>, eth1) and (<Access1IP>, 0/22) and (<Aggregate1IP>, 0/8) and (<Aggregate1IP>, 0/6) and (<Access2IP>, 0/18) and (<Host3IP>, eth2) and (VM6, VNIC6) or (VM3,VNIC3) and (<host1IP>,eth1) and (<Access1IP>, 0/22) and (<Aggregate2IP>, 0/8) and (<Aggregate2IP>,0/6) and (<Access2IP>,0/18) and (<Host3IP>,eth2) and (VM6, VNIC6) or (VM3, VNIC3) and (<host1IP>, eth2) and (<Access2IP>,0/18) and (<Host3IP>,eth2) and (VM6, VNIC6) or (VM3,VNIC3) and (<host1IP>, eth2) and (<Access1IP>,0/22) and (<Host3IP>, eth1) and (VM6, VNIC6)
An advantage of using a regular expression to represent the VNF link paths is that the NFV Monitor can take this regular expression, fill it out with the health status of each entity, such as the VNIC (VM3, VNIC3), or host NIC (<Host3IP>, eth2), or switchport (<Access1IP>, 0/22), and then feed it into a regular expression evaluation engine to calculate a boolean result from the expression. The result would be either ‘healthy (up)’ or ‘down’, which is the end result of the VNF link status between VNF-2115 and VNF-4125.
More specifically, when the regular expression engine evaluates the expression for example, the regular expression shown above, it follows the mathematical rule of the priority of operators. The ‘and’ operator will have higher priority than the ‘or’ operator. Therefore, the sub-clauses concatenated using ‘or’ in the expression can be evaluated separately. Each of the sub-clauses represent one valid path between the two VNFs. For each sub-clause, only all of the entities including VNICs, PNICs, Hosts, and switch ports are ‘UP’, the value of the sub-clause will be ‘UP’. If any of them is down, the value of the sub-clause is ‘DOWN’. Since the sub-clauses are concatenated with operator ‘or’, as long as one of the sub-clause has the value of ‘UP’, the entire expression will be ‘UP’. Only when all of the sub-clauses have the value ‘DOWN’, the entire expression will have the result ‘DOWN’. The regular expression evaluation process reflects the fact that when one of the paths between the two VNFs is good, the connectivity between these two VNFs is healthy.
The following list shows the definition of an end-to-end VNF link path regular expression.
(\(VM_ID, VNIC_ID\))?(and \(hostIP, PNIC\))?(and \(network_appliance_IP, portID\))+ (and \(hostIP, PNIC\))?(and \(VM_ID, VNIC_ID\))?(or (\(VM_ID,VNIC_ID\))?(and \(hostIP, PNIC\))?(and \(network_appliance_IP, portID\))+ and (\(hostIP, PNIC\))? and (\(VM_ID, VNIC_ID\))?)*
A VNF link path starts from the virtual NIC of the VM associated with one of the VNFs and ends with the virtual NIC of the VM associated with the other VNF in the input. If there are multiple VMs that construct multiple virtual links between the two VNFs, multiple regular expressions as above will be included in the output of the VNF Link Paths Locator.
In
As described above, NFV systems with network services provided by a service chain can run on top of a network environment with or without SDN Controller. In the embodiment when SDN Controller is not available in an NFV system, embodiments of the present invention can obtain the physical paths in the physical network topology through a configuration file; in the case when an SDN Controller is deployed in an NFV system, embodiments of the present invention can send a request to the SDN controller dynamically at run time to obtain the physical paths that connect the two physical NICs together.
In a configuration file, embodiments of the present invention can define the physical paths associated with two physical host NICs as two endpoints. The following is the definition of the regular expression for the specification of the physical paths info in the configuration file:
\[[hostIP|\(network_appliance_IP, portID\)], [hostIP|\(network_appliance_IP, PortID\)]\]=
\(hostIP, PNIC\)(and \(network_appliance_IP, portID\))+ and \(hostIP, PNIC\)(or \(hostIP, PNIC\)\(and \(network_appliance_IP, portID\))+ and \(hostIP, PNIC\))*
An example regular expression that specifies the physical paths would look like the following:
[host1IP, host3IP]=(<host1IP>, eth1) and (<Access1IP>, 0/22) and (<Aggregate1IP>, 0/8) and (<Aggregate1IP>, 0/6) and (<Access2IP>, 0/18) and (<Host3IP>, eth2) or (<host1IP>,eth1) and (<Access1IP>, 0/22) and (<Aggregate2IP>, 0/8) and (<Aggregate2IP>,0/6) and (<Access2IP>,0/18) and (<Host3IP>,eth2) or (<host1IP>, eth2) and (<Access2IP>,0/18) and (<Host3IP>,eth2) or (<host1IP>, eth2) and (<Access1IP>,0/22) and (<Host3IP>, eth1)
The expression captures the multiple physical paths between two physical NICs on two hosts in NFV system.
When the VNF link paths locator is initialized during NFV Monitor initialization, the VNF link paths locator can read the configuration file and load the regular expression into the memory. At runtime, if there is any change of physical network topology that would change the paths between any two hosts in the NFV system, the system administrator will modify the configuration file with the latest physical paths information. The VNF link paths locator can periodically monitor the configuration file to load the latest info.
With the physical paths information in the configuration file in regular expression formation, the VNF link paths locator will be able to generate end-to-end paths between two VNFs at any time upon receiving requests.
One embodiment uses a configuration file for the user to input the multiple paths between two host NICs in regular expression format. In another embodiment, a deployment embodiment, when there is an SDN Controller in the system that has the knowledge/information regarding the physical network topology, the manual input of the multiple paths between two host NICs can be used.
In the deployment embodiment, shown in
More specifically, during initialization of the NFV Monitoring System 405, the VNF link paths locator 420 can send a request to the SDN controller 415 to obtain the multiple paths information between any two physical host NICs in the NFV system 400. At runtime, whenever there is a physical network topology change, the SDN controller 415 can send an event notification to the VNF link paths locator 420. Upon receiving the notification, VNF link paths locator 420 can make another call to the SDN controller 415 asking for the updated physical paths info between any two hosts in the NFV system. The physical paths information would be:
Path1: (Host1, eth1)→(Access1, 0/22)→(Aggregate1, 0/8)→(Aggregate1, 0/6)→(Access2,0/18) (Host3, eth2))
Path2: (Host1,eth1)→(Access1, 0/22)→(Aggregate2,0/6) (Aggregate2, 0/6)→(Access2,0/18)→(Host3,eth2)
Path3: (Host1,eth1)→(Access1, 0/22)→(Access1,0/18)→(Host3,eth1)
Path4: (Host1,eth2)→(Access2, 0/22)→(Access2,0/18) (Host3,eth2)
The VNF link paths locator can generate the regular expression based on the above result. With this regular expression, VNF link paths locator could generate end-to-end link paths between any VNFs at any time when there is a request to this component asking for such information.
The output expression from the VNF link paths locator 420 can be used at the NFV monitoring system 405 for monitoring and analytics purposes.
More specifically, the output could be used in the following perspectives of an NFV monitoring system:
Using the expression, the system can evaluate the health status of the VNF link object between two VNF instances, the VNF to PNF links, or PNF to VNF links.
In the visualization of the VNF Forwarding Graph, when the user drills down into a VNF link, VNF to PNF links, or PNF to VNF links, multiple paths can be presented.
A similar approach can be used in other health status evaluation embodiments involving multiple underlying paths, such as redundant virtual and physical infrastructure to support application servers.
NFV data model 525 can contain data models for the physical hardware, the virtualized infrastructure, and the virtual network functions layers. NFV data query/reporting service 520 can retrieve data from NFV data model 525 to satisfy user queries and construct user defined reports related to the status of the network functions. For reporting the health status of the links between two virtual functions or one virtual function and one physical function, the NFV data query/reporting service 520 can communicate with VNF path locator 535 to achieve the purpose. Graphical interface 510 can communicate with NFV monitor northbound API 515 to visualize the status of the network functions. Upon receiving requests from the graphical interface 510, the northbound API 515 can delegate the requests to NFV data query/reporting service 520 to fulfill the user requests from the graphical interface 510. One advantage of the present invention is that it provides a component that is capable of reporting multiple virtual and physical network paths associated with a VNF link in a VNF service chaining scenario.
Another advantage of the present invention is that the VNF link paths locator described in the disclosure outputs a regular expression that can be used by the NFV Monitor to evaluate the status of the paths reported by the VNF link paths locator by feeding it to a regular expression evaluation engine.
Yet another advantage of the present invention is that it addresses the problem in NFV monitoring area to report the network service health status based on the evaluation of the VNF links that depend on multiple network paths in virtual and physical network layers of NFV architecture.
Yet another advantage of the present invention is that it fits into the scenario when NFV monitoring system does not have the capability to discover the underlying physical network topology of NFV systems.
One of ordinary skill in the art will appreciate that various benefits are available as a result of the present invention.
It shall be noted that aspects of the present invention may be encoded upon one or more non-transitory computer-readable media with instructions for one or more processors or processing units to cause steps to be performed. It shall be noted that the one or more non-transitory computer-readable media shall include volatile and non-volatile memory. It shall be noted that alternative implementations are possible, including a hardware implementation or a software/hardware implementation. Hardware-implemented functions may be realized using ASIC(s), programmable arrays, digital signal processing circuitry, or the like. Accordingly, the “means” terms in any claims are intended to cover both software and hardware implementations. Similarly, the term “computer-readable medium or media” as used herein includes software and/or hardware having a program of instructions embodied thereon, or a combination thereof. With these implementation alternatives in mind, it is to be understood that the figures and accompanying description provide the functional information one skilled in the art would require to write program code (i.e., software) and/or to fabricate circuits (i.e., hardware) to perform the processing required.
While the inventions have been described in conjunction with several specific embodiments, it is evident to those skilled in the art that many further alternatives, modifications, application, and variations will be apparent in light of the foregoing description. Thus, the inventions described herein are intended to embrace all such alternatives, modifications, applications and variations as may fall within the spirit and scope of the appended claims.
