Patent Description:
<CIT> relates to an 'App store portal providing point-and-click deployment of third-party virtualized network functions'. The publication "<NPL> concerns container-based virtualization in an NFV infrastructure.

The dependent claims define preferred embodiments.

According to the invention, a network function virtualization platform according to claim <NUM>, a method according to claim <NUM> and a computer program product according to claim <NUM> are disclosed.

NFV is a technology to run network functions, such as stateful firewalls, wide area network (WAN) accelerators, wireless local area network (LAN) controllers, and/or the like on a host system. For example, the network functions may be run as VNFs on hardware platforms. The VNFs can be virtual machines (VMs), Linux containers, and/or the like. The benefits of NFV may include elastic capacity, multi-vendor choice, easier deployment of services, remote management of the host system, and/or the like. An example use-case of NFV may include deployment on customer premises equipment (CPE), which may be managed remotely by a service provider.

On the host system, an NFV platform may manage communication of VNFs with physical interfaces of the host system, may manage lifecycles of VNFs, and may provide backbone networking support for service-chaining of VNFs. For example, VNFs may include similar software to software that runs on corresponding hardware appliances. Physical interfaces of a hardware appliance may be represented by virtual interfaces in the VNF. Multiple VNFs may be service-chained to provide a set of network services similar to those provided by hardware appliances, and traffic to and from the multiple VNFs may be received and transmitted via physical interfaces of the host system.

In some cases, a VNF may not be able to easily identify physical aspects of the host system, such as states of physical interfaces, parameters associated with the host system, internet protocol (IP) information, and/or the like. For example, the VNF may not be capable of monitoring such physical aspects, or it may be resource-intensive to probe physical interfaces. This may lead to problems, such as traffic black holing or packet loss, inferior transport control protocol/user datagram protocol (TCP/UDP) performance, and/or the like. These problems may further lead to additional problems for devices receiving services via the NFV platform as those devices may not receive traffic or packets as expected, resulting in failures, inoperability, and/or the like. Problems associated with VNFs being unable to identify aspects of the host system are described in more detail in connection with <FIG>, below.

Some implementations described herein may provide a communication channel and protocol for communication between the NFV platform and VNFs to exchange information regarding the host system and/or other VNFs. For example, some implementations described herein may provide a standardized messaging system to convey information regarding physical aspects of the host system to VNFs hosted on the host system or VNFs in communication with the host system. In this way, states of physical interfaces, parameters associated with the host system, internet protocol (IP) information, and/or the like can be communicated from the NFV platform to the VNFs, which improves performance of the VNFs and reduces the occurrence of problems relating to lack of visibility of physical aspects of the host system. Thus, VNF performance may be improved without requiring implementation of an external controller or resource-intensive monitoring operations by the VNFs. Further, network performance (e.g., of a network that includes the host system) may be improved relative to a network that does not include an NFV platform that conveys information regarding physical aspects of the host system to VNFs hosted on the host system or VNFs in communication with the host system.

<FIG> and <FIG> are diagrams of overviews of example implementations <NUM> and <NUM>' described herein. As shown in <FIG> and <FIG>, example implementations <NUM> and <NUM>' may include network device <NUM> and network device <NUM> and a host system including VNF router <NUM> and VNF router <NUM>.

As shown by reference number <NUM> in <FIG>, assume that a physical link between network device <NUM> and VNF router <NUM> fails, which may lead to traffic black holing (e.g., due to the VNF router <NUM> sending traffic to network device <NUM> through a failed physical link). As shown by reference number <NUM>, the VNF router <NUM> may lack visibility of a condition of physical links (e.g., a physical link between network device <NUM> and VNF router <NUM>) without expensive probing by VNF router <NUM> (i.e., without VNF router <NUM> frequently verifying an existing physical link with network device <NUM>). For this reason, the traffic en route to network device <NUM> may be lost because VNF router <NUM> does not have information indicating that the physical link with network device <NUM> has failed. As a result, and as shown by reference number <NUM>, VNF router <NUM> may advertise erroneous link information based on a presumption that the link to network device <NUM> is operational. As shown by reference number <NUM>, VNF router <NUM> may provide erroneous link information to VNF router <NUM> and to network device <NUM>. Accordingly, based on the erroneous link information, as shown by reference number <NUM>, network device <NUM> may continue to route traffic to VNF router <NUM> as a result, which may lead to traffic black holing or packet loss when VNF router <NUM> attempts to route the traffic through the failed physical link to network device <NUM>.

As shown in <FIG>, example implementation <NUM>' includes an NFV platform capable of providing an interface status message to VNF router <NUM> to address the erroneous link advertisements provided in <FIG>. As shown by reference number <NUM>, the NFV platform may detect a condition identifying the physical link failure. For example, the NFV platform may communicate with the host system to identify failed physical links or other information. As shown by reference number <NUM>, the NFV platform may identify interface information to be provided (e.g., may identify which physical interface is down, which physical interface is up, which physical interface has delays that satisfy a threshold, etc.) so that VNF router <NUM> can update a virtual interface status (e.g., to indicate that the virtual interface mapped to the failed physical interface is not to be used).

As shown by reference number <NUM>, the NFV platform may generate an interface status message (described in more detail with regard to <FIG>) identifying the interface information, and may provide the interface status message to VNF router <NUM>. For example, the NFV platform may provide the interface status message via a virtual serial interface, an IP interface, and/or the like. As shown by reference number <NUM>, the VNF router <NUM> may identify a physical interface link failure based on the interface status message. As shown by reference number <NUM>, the VNF router <NUM> may update link advertisements so traffic is rerouted. As shown by reference number <NUM>, VNF router <NUM> may provide updated link advertisements (based on identifying failure of the physical interface) to network device <NUM> and VNF router <NUM>. As shown by reference number <NUM>, network device <NUM> may use the updated link advertisement to determine that traffic is to be routed via VNF router <NUM>.

Some implementations described herein may provide a communication channel and protocol for communication between an NFV platform and VNFs to exchange information regarding the host system (that hosts the NFV platform and/or the VNFs) and/or other VNFs. For example, some implementations described herein may provide a standardized messaging system to convey information regarding physical aspects of the host system to VNFs hosted on the host system or VNFs in communication with the host system. In this way, states of physical interfaces, parameters associated with the host system, IP information, and/or the like can be communicated from the NFV platform to VNFs hosted by or in communication with the host system, which improves performance of the VNFs and reduces the occurrence of problems relating to lack of visibility of physical aspects of the host system. Thus, VNF performance may be improved without requiring implementation of an external controller or resource-intensive monitoring operations by the VNFs.

As indicated above, <FIG> and <FIG> are provided merely as examples. Other examples are possible and may differ from what was described with regard to <FIG> and <FIG>.

<FIG> is a diagram of an example environment <NUM> in which systems and/or methods, described herein, may be implemented. As shown in <FIG>, environment <NUM> may include an NFV platform <NUM> in a host system <NUM>, a cloud environment <NUM>, one or more VNFs <NUM>, <NUM>-<NUM> through <NUM>-N (N ≥ <NUM>) in the cloud environment and/or host system <NUM> (hereinafter referred to collectively as "VNFs <NUM>," and individually as "VNF <NUM>"), and one or more network devices <NUM>. Devices of environment <NUM> may interconnect via wired connections, wireless connections, or a combination of wired and wireless connections.

NFV platform <NUM> may include a platform or environment that includes one or more VNFs <NUM>. NFV platform <NUM> may manage a lifecycle of VNF <NUM>, and may provide backbone networking support for service-chaining of VNFs <NUM>. NFV platform <NUM>, in conjunction with VNF(s) <NUM>, may provide elastic capacity, multi-vendor choice for VNFs <NUM>, easier deployment of services, remote management of VNFs <NUM>, and/or the like. In some implementations, VNF <NUM> may include or be implemented on customer premises equipment (CPE) which may be managed remotely by a service provider. In some implementations, NFV platform <NUM> may communicate with host system <NUM> to receive, transmit, or route traffic between virtual interfaces associated with VNFs <NUM> and physical interfaces of host system <NUM>, as described in more detail below. For example, NFV platform <NUM> may be aware of a state of a physical interface of host system <NUM>. In some implementations, NFV platform <NUM> may include an operating system or kernel of host system <NUM>. Additionally, or alternatively, NFV platform <NUM> may communicate with an operating system or kernel of host system <NUM> to determine a state of a physical interface of host system <NUM>.

NFV platform <NUM> may be implemented on, associated with, or hosted by host system <NUM>. Host system <NUM> includes one or more devices capable of implementing NFV platform <NUM> and/or VNF(s) <NUM>. For example, host system <NUM> may include a server device or a group of server devices. Host system <NUM> may be associated with one or more physical interfaces (e.g., physical network interfaces, ports, backbone connections, hardware connections, etc.). In some implementations, host system <NUM> may include a server-class hardware platform.

VNF(s) <NUM> may include a VNF that performs a network function. For example, VNF <NUM> may include a stateful firewall, a WAN accelerator, a wireless LAN controller, a virtual router, a virtual switch, and/or the like. In some implementations, multiple VNFs <NUM> (e.g., tens of VNFs <NUM>, hundreds of VNFs <NUM>, and/or the like) may be implemented on host system <NUM>. Additionally, or alternatively, one or more VNFs <NUM> may be implemented in a cloud environment <NUM> that may be remote from host system <NUM>. Additionally, or alternatively, in some implementations, the cloud environment <NUM> may be implemented on host system <NUM>.

VNF <NUM> may receive and transmit information via a virtual interface. Mapping of virtual interfaces of VNFs <NUM> to physical interfaces of host system <NUM> may be handled by NFV platform <NUM>. In some implementations, VNF <NUM> may not be able to easily determine a status of a physical interface of host system <NUM>. For example, VNF <NUM> may be capable of probing a physical interface, but this may be resource-intensive.

Network device <NUM> includes one or more devices (e.g., one or more traffic transfer devices) capable of processing and/or transferring traffic. For example, network device <NUM> may include a firewall, a router, a gateway, a switch, a hub, a bridge, a reverse proxy, a server (e.g., a proxy server), a security device, an intrusion detection device, a load balancer, or a similar device. Network device <NUM> may receive, transmit, and/or route information based on route advertisements received from VNF(s) <NUM> and/or host system <NUM>.

In some implementations, network device <NUM> may be a physical device implemented within a housing, such as a chassis. In some implementations, network device <NUM> may be a virtual device implemented by one or more computer devices of a cloud computing environment or a data center.

<FIG> is a diagram of example components of a device <NUM>. Device <NUM> may correspond to NFV platform <NUM>, host system <NUM>, cloud environment <NUM>, and/or network device <NUM>. In some implementations, NFV platform <NUM>, host system <NUM>, cloud environment <NUM>, and/or network device <NUM> may include one or more devices <NUM> and/or one or more components of device <NUM>. As shown in <FIG>, device <NUM> may include a bus <NUM>, a processor <NUM>, a memory <NUM>, a storage component <NUM>, an input component <NUM>, an output component <NUM>, and a communication interface <NUM>.

Bus <NUM> includes a component that permits communication among the components of device <NUM>. Processor <NUM> is implemented in hardware, firmware, or a combination of hardware and software. Processor <NUM> takes the form of a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), a microprocessor, a microcontroller, a digital signal processor (DSP), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), or another type of processing component. In some implementations, processor <NUM> includes one or more processors capable of being programmed to perform a function. Memory <NUM> includes a random access memory (RAM), a read only memory (ROM), and/or another type of dynamic or static storage device (e.g., a flash memory, a magnetic memory, and/or an optical memory) that stores information and/or instructions for use by processor <NUM>.

Communication interface <NUM> includes a transceiver-like component (e.g., a transceiver and/or a separate receiver and transmitter) that enables device <NUM> to communicate with other devices, such as via a wired connection, a wireless connection, or a combination of wired and wireless connections. Communication interface <NUM> may permit device <NUM> to receive information from another device and/or provide information to another device. For example, communication interface <NUM> may include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a universal serial bus (USB) interface, a Wi-Fi interface, a cellular network interface, and/or the like.

Device <NUM> may perform one or more processes described herein. Device <NUM> may perform these processes based on processor <NUM> executing software instructions stored or carried by a computer-readable medium. A computer readable medium may include non-transitory type media such as physical storage media including storage discs and solid state devices. A computer readable medium may also or alternatively include transient media such as carrier signals and transmission media. A computer-readable storage medium is defined herein as a non-transitory memory device. A memory device includes memory space within a single physical storage device or memory space spread across multiple physical storage devices. For example, software instructions may be stored or carried by a non-transitory computer-readable storage medium, such as memory <NUM> and/or storage component <NUM>.

<FIG> is a flow chart of an example process <NUM> for synchronization between host system <NUM> and VNFs <NUM>. In some implementations, one or more process blocks of <FIG> may be performed by NFV platform <NUM>. In some implementations, one or more process blocks of <FIG> may be performed by another device or a group of devices separate from or including NFV platform <NUM>, such as host system <NUM>, VNF(s) <NUM>, and/or network device <NUM>.

As shown in <FIG>, process <NUM> may include identifying a condition associated with one or more VNFs (block <NUM>). For example, NFV platform <NUM> may identify a condition associated with one or more VNFs <NUM>.

In some implementations, one or more VNFs <NUM> may be hosted by a host system <NUM> associated with NFV platform <NUM>. Additionally, or alternatively, one or more VNFs <NUM> may be remote from host system <NUM> and/or NFV platform <NUM> (e.g., in cloud environment <NUM>). In some implementations, NFV platform <NUM> may identify first information associated with VNFs <NUM>. In this case, the first information may include information that identifies the condition, and/or may include other information regarding VNFs <NUM> (e.g., a status of VNFs <NUM> and/or the like).

In some implementations, the condition may relate to a physical interface or physical aspect of host system <NUM>. For example, the condition may relate to a status of a physical link, a network interface controller (NIC) configuration, an IP address configuration, and/or the like. In some implementations, the condition may be detected by NFV platform <NUM> (e.g., based on monitoring physical links, based on negative acknowledgements (NACKs) from a downstream device, based on information obtained from host system <NUM>, etc.).

In some implementations, NFV platform <NUM> may receive information identifying the condition. For example, an operating system of host system <NUM> may communicate with NFV platform <NUM> to identify the condition. As another example, VNFs <NUM> may provide information identifying the condition. In this case, VNFs <NUM> may provide the information via a serial interface (e.g., a virtio-serial interface) or an IP interface.

In some implementations, a condition may not be detectable by a VNF <NUM>, so NFV platform <NUM> may use a communication channel and protocol described herein to generate and provide a message to VNF <NUM> identifying the condition and/or causing an action to be performed with respect to the VNF <NUM> or the condition, as described in more detail below.

As an example of a scenario in which NFV platform <NUM> may identify a condition associated with the one or more VNFs <NUM>, assume that a router VNF <NUM> is implemented on NFV platform <NUM> with a set of virtual interfaces. In this case, assume that the virtual interfaces are operational and the routing protocols running in the router VNF <NUM> advertise links with which the virtual interfaces are associated, irrespective of the link status of the physical ports associated with the virtual interfaces. This can lead to black holing of traffic in the event of link failure of one or more of the physical ports of host system <NUM> as the router VNF <NUM> may continue to route traffic to the failed link, resulting in packet loss. In some implementations, the NFV platform <NUM> may detect the failed link condition through communication with the host system <NUM> (e.g., via a message exchange of one or more of the example messages described below).

As another example of a scenario in which NFV platform <NUM> may identify a condition associated with the one or more VNFs <NUM>, assume that VNF <NUM> (e.g., a software-defined wide area network (SD-WAN) VNF) is associated with a primary interface (e.g., a <NUM> Ethernet interface) and a secondary interface (e.g., a long term evolution (LTE) interface), and the VNF <NUM> is configured to route packets out over the primary interface when the primary interface is operational, and to switch to the secondary interface when the primary interface is not operational. In this case, the VNF <NUM> may have no direct way of determining whether the primary interface is operational. In some implementations, the NFV platform <NUM> may detect that the condition of the primary interface not being operational based on communication with the host system <NUM> (e.g., via a message exchange of one or more of the messages described below).

As another example of a scenario in which NFV platform <NUM> may identify a condition associated with the one or more VNFs <NUM>, assume that VNFs <NUM> utilize a traceroute function, and it is beneficial to enhance the traceroute function to provide information on where the VNFs <NUM> are implemented. In this case, the VNFs <NUM> may have no information associated with a platform (e.g., the NFV platform <NUM> or host system <NUM>) that is hosting the VNFs <NUM>. In some implementations, the NFV platform <NUM> may detect a traceroute condition and facilitate providing such information on the VNFs <NUM> to one another based on communication with the host system <NUM> and the VNFs <NUM> (e.g., via one or more message exchanges of one or more of the messages described below).

As another example of a scenario in which NFV platform <NUM> may identify a condition associated with the one or more VNFs <NUM>, assume that NFV platform <NUM> provides password-free, yet secure, access to VNFs <NUM> that NFV platform <NUM> (or the host system <NUM>) hosts, which may aid in Zero Touch Provisioning (ZTP) of the VNFs <NUM> and saving IP addresses (e.g., such that a remote controller can reach any VNF <NUM> via a single IP address). In this case, when VNFs <NUM> are activated, a user (e.g., a network administrator) may manually log into each VNF <NUM> and set up password-free access to that VNF <NUM>, which may be cumbersome if a service provider is managing numerous (e.g., thousands) of NFV platforms, each running tens or hundreds of VNFs <NUM>. Accordingly, in some implementations, NFV platform <NUM> may detect the password-free access condition of VNFs <NUM> using the communication framework between host system <NUM> and VNFs <NUM> described herein and enable the password-free access to VNFs <NUM> as described below.

As another example of a scenario in which NFV platform <NUM> may identify a condition associated with the one or more VNFs <NUM>, assume that a VNF <NUM> is associated with a flow/session-based data plane and terminating/starting transmission control protocol (TCP) sessions. In a pure appliance-based environment, such a flow-based system may utilize the NIC's TCP checksum offload/TCP segmentation offload (TCO/TSO), to accelerate TCP performance. In a VNF-based environment, a VNF <NUM> may have only virtual interfaces and, for this reason, may not have information identifying whether the actual physical NIC (which is typically WAN facing) on the host system <NUM> is capable of TCO/TSO functions. In this case, the VNF <NUM> cannot take advantage of TCO/TSO capabilities on the NIC, which may result in inferior TCP/UDP performance. In some implementations, NFV platform <NUM> may detect the condition in which VNFs <NUM> may take advantage of TCO/TSO functions of a NIC of the host system <NUM> (e.g., when VNFs <NUM> have a flow/session-based data plane), and facilitate communication between the host system <NUM> and VNFs <NUM> to enhance TCP/UDP performance via the TCO/TSO functions of the NIC.

As further shown in <FIG>, process <NUM> may include determining information to be provided or an action to be performed with regard to the one or more VNFs based on the condition (block <NUM>). For example, NFV platform <NUM> may determine information to be provided with regard to the one or more VNFs <NUM> based on the condition. Additionally, or alternatively, NFV platform <NUM> may identify an action to be performed with regard to the one or more VNFs <NUM> based on the condition.

In some implementations, the information may identify the condition, may identify parameters or information associated with the condition, and/or the like. For example, for a link failure or link creation condition, the information may identify a name of a physical interface, an address of the physical interface, and/or an operational state of the physical interface. As another example, for an IP provisioning condition, the information may identify an IP address, subnet mask, gateway IP address, domain name server (DNS) address, and/or the like. As yet another example, for a NIC interface condition, the information may identify a name of a NIC, a maximum transmission unit (MTU) of a NIC, whether TCO and/or TSO is enabled, and/or the like. As still another example, for host information of the host system <NUM>, the information may identify a host name, host IP address, and/or the like. As another example, for zero-touch provisioning (ZTP), the information may identify a file location of a ZTP file on the host system <NUM>.

In some implementations, the action may be performed by VNF <NUM> based on the information. For example, for a link failure, the action may include sending an updated route advertisement. As another example, for IP provisioning, the action may include configuring communication using the IP information. As yet another example, for a NIC, the action may include configuring communication with the NIC. As still another example, for ZTP, the action may include configuring VNFs <NUM> based on the ZTP file.

As further shown in <FIG>, process <NUM> may include generating or transmitting a message including the information and/or to cause the action to be performed with regard to VNFs <NUM> (block <NUM>). For example, NFV platform <NUM> may generate and transmit a message to VNFs <NUM> and/or cause host system <NUM> to generate or transmit a message to VNFs <NUM>. Additionally, or alternatively, NFV platform <NUM> may cause an action to be performed by VNFs <NUM> and/or cause an action to be performed with respect to VNFs <NUM>.

In some implementations, NFV platform <NUM> may transmit the message via a serial interface, such as a virtio-serial interface or a similar interface between NFV platform <NUM> (or host system <NUM>) and the one or more VNFs <NUM>. In this way, NFV platform <NUM> may transmit the message via an interface that is uncomplicated relative to transmitting the message other than via a serial interface, that is always available, and/or that can work without IP connectivity between VNF <NUM> and NFV platform <NUM> (or host system <NUM>).

In some implementations, NFV platform <NUM> may transmit the message via another type of interface, such as an IP interface. For example, when VNF <NUM> is remote from NFV platform <NUM>, no serial interface may exist between VNF <NUM> and NFV platform <NUM>. In such a case, NFV platform <NUM> may use an IP interface.

In some implementations, messages exchanged between the NFV platform <NUM>, the host system <NUM>, and/or VNFs <NUM> may have a particular format (e.g., based on a particular protocol). In some implementations, the format may be extensible, which may provide adaptability of the messaging format described herein. An example of the message format with Type-Length-Value (TLV) fields is shown below:.

The below table provides possible information values for an example protocol packet format:.

In some implementations, NFV platform <NUM> may use the communication channel and protocol described herein to address the example scenarios described in connection with block <NUM> of <FIG>, above.

With regard to the physical interface outage scenario described above, whenever physical links become non-operational or operational (e.g., go "down" or "up"), NFV platform <NUM> may notify VNF <NUM> by generating and/or transmitting an INTERFACE STATUS message, as described above. In this case, VNF <NUM> may map the message to one or many of its virtual interfaces. On receiving this message, VNF <NUM> may modify the virtual interface status accordingly, and may update routing protocols to advertise accurate reachability information that reflects an actual physical connectivity.

With regard to the primary interface outage scenario described above, platform software of NFV platform <NUM> may detect a loss of a primary link and switch over to a secondary link. In this case, NFV platform <NUM> may generate and/or transmit an INTERFACE STATUS message, as described above, that identifies the primary interface and a status of the primary interface ("down" in this case). By sending the INTERFACE STATUS message, VNF <NUM> may trigger a switchover to the secondary interface.

With regard to the traceroute scenario described above, a traceroute function may be modified to an enhanced version of the traceroute function where not only IP addresses of the hops are listed, but also more details about each hop (e.g., a type of device, hostname of the device, and location) are listed. In some implementations, NFV platform <NUM> may generate and/or transmit a HOST INFO message, as described above, and may share a host name of host system <NUM> with VNF <NUM> in the HOST INFO message. In this case, VNF <NUM> may add the information in trace probes so as to identify VNF <NUM> as a VNF, and to identify where VNF <NUM> is hosted. For example, the VNF <NUM> host name, location, etc. may be useful in troubleshooting or providing visibility into virtualized networks.

With regard to the ZTP scenario described above, by using the communication framework described herein between NFV platform <NUM>, host system <NUM>, and VNFs <NUM>, a need to manually log into each VNF <NUM> may be avoided, and the access process may be automated. For example, once a public key is set up, the public key may be exported by NFV platform <NUM> generating and/or transmitting an SSH PUBLIC KEY message, as described above, to VNFs <NUM>. In this case, if required, NFV platform <NUM> may generate and/or transmit a ZTP INFO message, as described above, to VNF <NUM> to bootstrap the VNF <NUM> with a custom configuration.

With regard to the NIC interface scenario described above, NFV platform <NUM> may advertise the capabilities of WAN facing NIC to VNFs <NUM> by generating and/or transmitting an INTERFACE CAPABILITY message, as described above. In this case, VNF <NUM> may adjust its TCP protocol stack to turn on TCO/TSO functionality, giving better TCP/UDP performance.

In this way, some implementations described herein may provide efficient techniques for remedying frequently-encountered problems or limitations in scenarios associated with Virtual Network Functions.

In some implementations, a message may include a direction element. For example, the direction element may indicate whether host system <NUM> is transmitting the message to VNF <NUM>, or whether VNF <NUM> is transmitting the message to the host system <NUM>. In this way, a message transmitted in the wrong direction (e.g., a direction inconsistent with an actual direction of the message) may be silently discarded, which may protect the host system <NUM> from misuse of the protocol to obtain sensitive information.

As a particular example, SSH PUBLIC KEY messages are intended to be sent from host system <NUM> to VNFs <NUM>, rather than from VNFs <NUM> to host system <NUM>. If host system <NUM> receives an SSH PUBLIC KEY message from a VNF <NUM>, the SSH PUBLIC KEY message may be treated as an attack based on the direction element, the packet may be silently discarded, and/or the event may be reported to an administrator. Additionally, or alternatively, the variety of information exported to VNF <NUM> by host system <NUM> may be limited to network events and basic operational needs, and may not include sensitive information regarding host system <NUM>. Additionally, or alternatively, NFV platform <NUM> may install IP table rules to discard unwanted or unexpected packets from VNFs <NUM>. In this way, security of NFV platform <NUM> and/or host system <NUM> may be improved.

Some implementations described herein may provide a communication channel and protocol for communication between an NFV platform and VNFs to exchange information regarding the host system and/or other VNFs. For example, some implementations described herein may provide a standardized messaging system to convey information regarding physical aspects of the host system to VNFs hosted on the host system. In this way, states of physical interfaces, parameters associated with the host system, IP information, and/or the like can be communicated from the NFV platform to the VNFs, which improves performance of the VNFs and reduces the occurrence of problems relating to lack of visibility of physical aspects of the host system. Thus, VNF performance may be improved without requiring implementation of an external controller or resource-intensive monitoring operations by the VNFs. As a result of improved VNF performance, devices utilizing the VNFs or receiving a service via the VNFs may receive improved performance and avoid traffic black holing or packet loss.

Therefore, from one perspective, there has been described that a network function virtualization (NFV) platform may include one or more processors to identify a condition associated with the NFV platform, where the condition may affect operation of at least one virtual network function (VNF) hosted by or associated with the NFV platform; determine, based on the condition, information that may be provided or an action that may be performed with regard to the at least one VNF; and/or generate or transmit a message identifying the information and/or that may cause the action to be performed with regard to the at least one VNF.

As used herein, the term component is intended to be broadly construed as hardware, firmware, and/or a combination of hardware and software.

Thus, the operation and behavior of the systems and/or methods were described herein without reference to specific software code-it being understood that software and hardware can be designed to implement the systems and/or methods based on the description herein.

Claim 1:
A network function virtualization, "NFV", platform, comprising:
one or more processors to:
identify a condition associated with the NFV platform (<NUM>),
where the condition affects operation of at least one virtual network function, "VNF", (<NUM>) hosted by or associated with the NFV platform, and
where the condition is associated with a physical interface associated with the NFV platform;
determine, based on the condition, information to be provided and an action to be performed with regard to the at least one VNF; and
transmit a message identifying the information to the at least one VNF and to cause the action to be performed with regard to the at least one VNF.