NETWORK FUNCTION VIRTUALIZATION (NFV)

Abstract

Network function virtualization (NFV) or other cloud/remote processing of packets, signals, messaging, etc. for a home network or other network desiring remote management is contemplated. A virtual platform or other feature outside of the managed network may be configured to implement various NFVs according to NFV designs. An administrator of the managed network may interact with a portal or other relatively unsophisticated interface to formulate the NFV designs, thereby eliminating or ameliorating complexities associated with the administrator having to individually program routers or other devices of the managed network.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. provisional Application No. 62/019,473 filed Jul. 1, 2014, the disclosure of which is incorporated in its entirety by reference herein.

TECHNICAL FIELD

The present invention relates to facilitating network function virtualization (NFV), such as but not necessary limited to facilitating NFV on packets, frames and/or signaling associated with a home network or other network where configuration of routers or other devices may be difficulty for an associated subscriber/customer.

BACKGROUND

Home networks are growing more sophisticated; customers are not. As home networks become more complicated, many customers are looking to MSOs to support these more complicated networks, and MSOs need tools to support them. Network virtualization using technologies such as Software Defined Networking (SDN) and Network function Virtualization (NFV) provides such a set of tools. Generally speaking, SDN describes an open architecture comprising a set of APIs, and control protocols such as Open Flow that allow for dynamic, distributed provisioning and automation. NFV decouples network functions such as firewalls, deep packet inspection, caching, etc., from proprietary hardware so that they can be run in software on generic (e.g., x86) servers. While SDN and NFV can be implemented independently, one non-limiting aspect of the present invention contemplates the benefits multiplying when the technologies are combined

Home networks are evolving. Most subscribers today connect to the Internet using a home router or ISP supplied Modem/Router combination. Subscribers are connecting additional routers to their networks to extend the reach of their WiFi, or to add services such as home automation and security, IP video, and sensor networks (e.g., Internet of Things). Home routers, however, typically do not run a routing protocol, and networking these routers was challenging, and usually resulted in multiple layers of IPv4 Network Address Translation (NAT). As customers are interconnecting devices within the home for video streaming or remote printing from tablets, these multiple layers of NAT are problematic and severely hamper these in-home services.

To address these problems, HIPNet™ was developed as a new architecture for leveraging IPv6 provisioning to automatically configure home routers into a routable network without requiring NAT on interior routers. HIPNet functionality is becoming available on cable eRouters, and represents a significant improvement over previous technology. However, some challenges still remain. Service Discovery across routers (e.g., to allow Smart TVs to locate DLNA media servers) is challenging, and MSOs do not have an easy way to manage this proliferation of home routers on behalf of their subscribers. In addition, it is difficult to add new home network services, as they rely on the capabilities of the routers already deployed, and may require a new device to support new features.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a network function virtualization (NFV) system in accordance with one non-limiting aspect of the present invention.

FIG. 2 illustrates operation a virtual platform in accordance with one non-limiting aspect of the present invention.

FIG. 3 illustrates zoning of a home network in accordance with one non-limiting aspect of the present invention.

FIG. 4 illustrates a messaging diagram for a method of facilitating NFV in accordance with one non-limiting aspect of the present invention.

FIG. 5 illustrates an NFV portal in accordance with one non-limiting aspect of the present invention.

FIG. 6 illustrates a messaging diagram for a method of facilitating NFV in accordance with one non-limiting aspect of the present invention.

DETAILED DESCRIPTION

As required, detailed embodiments of the present invention are disclosed herein; however, it is to be understood that the disclosed embodiments are merely exemplary of the invention that may be embodied in various and alternative forms. The figures are not necessarily to scale; some features may be exaggerated or minimized to show details of particular components. Therefore, specific structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a representative basis for teaching one skilled in the art to variously employ the present invention.

FIG. 1 illustrates a network function virtualization (NFV) system 10 in accordance with one non-limiting aspect of the present invention. The system 10 illustrates one exemplary configuration where a virtual platform 12 associated with an outside network 14 facilitates communications with an edge router 18 of a home or inside network 20, such as in the manner described in U.S. patent application Ser. Nos. 13/792,016, 14/250,444 and 14/668,389, the disclosures of which are hereby incorporated by reference in their entireties herein. The system 10 demonstrate one exemplary, non-limiting use of the present invention where a multiple system operator (MSO), Internet service provider (ISP), cellular service provider or other type of service provider facilitates Internet-based messaging or other network-based messaging/signaling between one or more servers 22, etc. connected to the Internet or network external to the home network 20. The home network 20 may include a plurality of interconnected, internal routers (IRs) and devices. The signaling associated with facilitating messaging or other exchanges between the servers 22 and the devices may be wireless and/or wired signaling and occurring according to any suitable protocol or standard.

While only one inside network 20 is illustrated, the MSO may be responsible for facilitating NFV for any number of inside networks or other downstream connected networks. In addition to facilitating NFV, the virtual platform 12 or other feature of the MSO may be responsible for providing other services to the home network 20 and devices associated therewith, such as provisioning related services where DHCP or other functions are performed to assign prefixes or other addressing information to the home network prior to facilitating the contemplated NFV. The home network 20 may be arranged in a hierarchical order with the edge router 18, which may be periodically referred to herein as a customer edge router (CER) or edge router (ER), connected to the MSO network with a plurality of routers connected downstream thereof in a multi-layered arranged, the routers below the edge router may be periodically referred to herein as internal routers (IRs). Optionally, the ER, IRs and/or devices may be configured to receive multiple prefixes, such as in the manner described in U.S. patent application Ser. No. 13/754,954, Reverse Prefix Delegation, the disclosure of which is hereby incorporated by reference in its entirety.

A five layer architecture is shown to correspond with a first layer having the ER, a second layer having one or more IRs connected directly to the ER, a third layer having one or more IRs and/or devices connected to one of the second layer IRs, a fourth layer having one or more IRs and/or devices connected to one of the third layer IRs, and a fifth layer having one or more devices connected to one of the fourth layer IRs. The IRs and/or devices are shown to be connected to a single upstream ER or IRs as such devices may be configured to listen to no more than one delegating router/device on a network link (solid lines) in order to comply with DHCP requirements. The single-connection of each component is shown for exemplary non-limiting purposes as the present invention fully contemplates the inside network having any number of configurations and interconnections between the ER, IRs and/or devices. One non-limiting aspect of the present invention contemplates the ER and/or the IRs being HlPnet routers or other consumer-level routers having off-the-shelf, default, pre-configured and/or consumer-level configurations whereby operations may be automatically performed or implemented without user/manual manipulation and programming, such as that described in The Internet Engineering Task Force (IETF) Internet draft entitled A Near Term Solution for Home IP Networking (HIPnet) draft-grundemann-hipnet-00 (updated draft 01 draft-grundemann-homenet-hipnet-01) and U.S. provisional application serial No. 61/771,807, the disclosures of which are hereby incorporated by reference in their entireties herein. The multi-router network 20 may also include non-HlPnet routers or routers otherwise lacking capabilities for performing the out-of-the-box functionality associated with the HlPnet routers.

FIG. 2 schematically illustrates operation of the virtual platform 12 being configured to address various home network complexities using NFV in accordance with one non-limiting aspect of the present invention. The virtual platform 12 may be considered as a cloud device or other construct operating independently of the home network 20 and devices connected thereto, i.e., the functions and operations performed by the virtual platform 12 may be independent of the functions and operations being performed at the ER or IRs of the home network 20. The operation of the virtual platform 12 is shown for exemplary non-limiting purposes with respect to processing of packets, such as IP packets, for exemplary non-limiting purposes as the present invention fully contemplates processing any other type of message or signal, e.g. Ethernet frames. The virtual platform 12 may be configured with an input/output (I/O) 26, 28 operable to receive messages from one or more of the servers 22 and/or one or more of the inside networks 20. The packets shown to be entering the virtual platform 12 may be characterized as traveling in an upstream direction when originating from the home network 20 and may be characterized as traveling in a downstream direction when originating from one of the servers 22. The virtual platform 12 may include capabilities sufficient to facilitate simultaneously processing multiple packets and/or multiple packet streams in both of the upstream and downstream directions.

Three signaling streams 30, 32, 34 are shown for exemplary non-limiting purposes to demonstrate the capabilities of the virtual platform 12 to selectively apply one or more of a plurality of network virtualizations (NFVs) to each of the streams. A first stream 30, which may be characterized as traveling in a downstream direction, may be subjected to a first NFV (NFV #1), a third NFV (NFV #3) and a fourth NFV (NFV #4) before being subsequently transmitted to the home network 20. A second stream 32, which may also be characterized as traveling in a downstream direction, may be subjected to a second NFV (NFV #2), the third NFV (NFV #3) and a fifth NFV (NFV #5) before being subsequently transmitted to the home network 20. A third stream 34, which may be characterized as traveling in an upstream direction, may be subjected to the first NFV (NFV #1) and an nth NFV (NFV nth) before being subsequently transmitted to one of the servers 22. The noted streams 30, 32, 34 are exemplary and illustrative of the virtual platform 12 being capable of simultaneously performing NFV on any number of packets in any direction, e.g., the first NFV is shown to be simultaneously applied to upstream and downstream packets and the third NFV is shown to be simultaneously applied to different downstream packets. The virtual platform may include a memory (not shown) having a plurality of non-transitory computer-readable instructions operable with a processor (not shown) to facilitate the operations contemplated herein.

The virtual platform 12 or capabilities associated therewith (the MSO may include SDN and/or any number of other devices to facilitate the contemplated NFVs) may provide a solution to the growing complexity of subscriber home networks by virtualizing management of the home network for management by the MSO (or the subscriber via a self-service portal). The offsite management may enable users to move beyond the device-centric architecture and consider a virtualized service-centric architecture, which offers MSOs the ability to better manage subscriber networks and to understand how customers are using them, and offers subscribers a way to tailor the network to optimize their specific use cases such as gaming or video streaming. Many problems experienced in a routed home network, such as service discovery, multiple firewalls, and multicast forwarding, become simpler in a layer 2 (bridged) network, however, existing devices and/or home networks typically include routers. The present invention combats these problems as well as addressing needs of emerging services, such as Smart Grid or home automation, and the needs of routed networks for security purposes or to satisfy regulatory requirements.

FIG. 3 illustrates a zoning 40 of the home network in accordance with one non-limiting aspect of the present invention. In the contemplated virtualized home network, the present invention can have the best of both worlds through such zoning. First, the home network 20 can be separated into different logical policy domains, such as for Internet access, guest access, VPNs, or in-home video sharing. Each zone 42, 44, 46, 48, 50 can be assigned its own firewall, connectivity policies, etc. via the NFVs associated with the virtual platform 12. Next, each zone 42, 44, 46, 48, 50 may be distributed throughout the house using encapsulation techniques such as VXLAN, VLAN, IPv6 flow labels, etc. Finally, devices/hosts may be assigned to one or more zones 42, 44, 46, 48, 50, and devices can receive multiple IPv6 addresses such that they may receive unique addresses for each zone or other methods of membership in a zone such belonging to the same VLAN or using another identifier indicating zone membership. Optionally by default, the devices can be assigned to the Internet or Guest zone (for a Guest WiFi network) but could be assigned to different zones, as well.

Within each zone 42, 44, 46, 48, 50, which could stretch across router boundaries, traffic may be bridged, which may offer subscribers an improved quality of experience. No longer would nested internal NAT functionality interfere with printing or video streaming, and link-scoped service discovery mechanisms such as mDNS would show all the devices in a particular zone, rather than just those devices on the local subnet. When the home network 20 first comes online, it may need a basic level of automatic configuration support plus a path to reach the MSO virtual platform 12. HIPNet, included in eRouter devices, provides this level of connectivity using DHCPv6 prefix delegation to provision routers in a tree topology and establish routes to all the devices. It may be optimized for Internet connectivity, and also supports host-to-host communication. Once network connectivity is established, the home routers can contact the MSO virtual platform for optimized forwarding instructions using protocols such as Open Flow or TR-069.

To create optimized forwarding paths, the MSO virtual platform can collect topology information from the home network devices, e.g., the home routers can collect this topology information using Link Layer Discovery Protocol (LLDP) and communicate it to the MSO controller using Open Flow or similar protocols. The MSO controller can then use the Dijkstra algorithm (also used in routing protocols such as OSPF and ISIS) to compute optimal forwarding paths and communicate them back to the subscriber's routers. Subscriber routers can also collect and report attached host MAC and IP addresses to help troubleshoot issues that may arise in the home and to further optimize traffic forwarding. In the event of an Internet connectivity failure, this architecture would allow the network to use a backup connectivity mechanism such as WiFi. If that is not available, the home network will continue to operate, albeit with more basic HIPNet functionality. Thus, the MSO controller provides optimizations when the service is connected, but the home has local survivability.

The virtual platform 12, or its routers, servers, switches, etc., can be associated with the home network 20 and/or devices to perform a number of NFVs on behalf of the customer. These features may be generically divided into two types: control plane and data plane. The control plane features may look at packet headers and enforce policy on a network, while data plane features may be inserted in the traffic forwarding path and affect the payload of the traffic. While not an exhaustive list, control plane features may include:

• • Network Address Translation (NAT), which provides differentiation between customer space and public space and which is used to manage IPv4 address scarcity during the transition to IPv6, which may include change an IPv4/IPv6 address included in a packet to and IPv6/IPv4.
  • Firewall, which enforces security policy on the network, such as whether packets from/to a particular domain are permitted to pass through the virtual platform or are stop from further transmission.
  • Routing and forwarding, which identifies the optimal paths to send traffic through the network.
  • Virtual Private Networks (VPNs), which provide private connectivity to remote networks such as corporate offices.
  • IPv6 transition technologies.

Likewise, the data plane features may include:

• • Dynamic Host Configuration Protocol (DHCP) and Domain Name Service (DNS), which provision devices with IP addresses and provide database lookup services to identify other hosts.
  • Deep Packet Inspection, which looks into packet payloads and helps with Denial of Service and Parental Controls.
  • Denial of Service protection, which looks for traffic anomalies and block unwanted traffic streams.
  • Parental Controls, which block objectionable content.

Until now, these features have generally been offered on home routers, and configured separately on each router. This has led to a sub-optimal experience for subscribers, who have looked to the teenager down the street or commercial services to configure their routers. With network virtualization techniques contemplated herein, MSOs can host all of these services in their data centers and offer them to subscribers as cloud services. In addition, customers are interested in some control plane features that are not widely available today, either because they have not been possible, or because they have been difficult to implement with existing devices, but that could be delivered according to the present invention. These may include:

• • Bandwidth on demand, where subscribers can change bandwidth levels on the fly to accommodate large file transfers (e.g., downloading a movie before a flight).
  • Priority service for video or gaming services, allowing subscribers smooth delivery of entertainment content.

Once the virtual network of the present invention is in place, it allows MSOs to offer new network services such as Bandwidth on Demand or enhanced service levels for high-value content such as video streaming or gaming. The home network 20 described above offers benefits for both MSOs and subscribers. MSOs benefit from reduced expenses, faster time-to-market with new services, and optimized use of deployed reserves. Subscribers benefit from mass-customized services and service-centric policies (as opposed to device-centric policies today). MSOs stand to benefit from reduced expenses, as this virtualized network architecture allows for self-service provisioning via a web portal, simplified upgrades managed by DevOps tools such as Puppet and Chef, and simplified inventory management and certification testing, as the functionality is delivered in software, rather than via specific devices. It also gives MSOs more visibility into the devices attached to the subscriber network, helping them troubleshoot and optimize the network on the subscriber's behalf. As network functions are deployed in software, this architecture offers MSOs shorter build-measure-learn development cycles that will bring new features to market faster. Finally, as virtualized network reserves can be shared across multiple subscribers, it allows MSOs to optimize the use of deployed reserves.

For subscribers, network virtualization offers a mass-customized Internet service. Just as we have seen with cellphone app stores, subscribers value different aspects of a service. Under this approach, they can drag and drop those features that are important to them. For example, an avid gamer might select optimized gaming service, while parents might opt for strict parental controls. As services can be tailored to individual subscriber needs, this approach offers an enhanced quality of experience over today's networks. In addition, network policies are tied to the user, and not the device. This allows subscribers to have the same Internet experience at home or on the road through Cable WiFi. The contemplated network virtualization allows MSOs to offer subscribers a new network architecture that is mass-personalized, automated, and tailored to individual needs. This architecture includes service-(or policy-) specific overlay zones that can be extended into the MSO data center to allow delivery of MSO-managed network features. From the data center, MSO SDN controllers can push policy to individual network devices, optimizing network forwarding paths and enforcing firewall policies. These changes offer improved economics to MSOs and an improved quality of experience to subscribers.

FIG. 4 illustrates a messaging diagram for a method of facilitating NFV in accordance with one non-limiting aspect of the present invention. The various operations associated with and/or other process necessarily to the method may be embodied in a computer-readable medium having a plurality of non-transitory transitory instructions operable with a processor or other logically functioning element of the devices attendant thereto. The NFVs are described for exemplary non-limiting purposes with respect to various virtualization performed at the virtual platform 12 in order to manipulate packets, messaging or other signaling transmitted from/to a network 20 having a plurality of devices, such as in the above-described manner where an MSO or other provider executes the NFV for on the behalf of an edge router 18, gateway or other interface to the home network 20 connected to the devices. As shown in FIG. 2, the NFVs may generally correspond with the virtual platform 12 adapting, manipulating or otherwise alternating received packets or the like for subsequent transmission with added, removed, replaced or other changes to data, addresses, content, markers, etc. include in the packets when received (varies depending on the one or more NFVs and/or the ordering in which the NFVs are performed) and/or selecting routing, tunnels, priority and optimizations for communication of the packets (the packets may be considered as modified when route, etc. according to one of the NFV even when there is no alteration of the packet contents (e.g. payload and/or headers).

A service discovery process(s) 60, 62 may include the virtual platform 12 identifying the devices associated with the home network 20 (services, etc. could similarly be discovered and are referred to a devices for exemplary purposes). The discovered device(s) may be determined as a function of corresponding messages exchanged between the virtual platform 12 and devices or edge router 18, messages reported from the edger router 18 following its discovery of the devices and/or through other suitable mechanisms, such as those described in the above-referenced patent applications and/or U.S. patent application Ser. Nos. 14/334,027, 62/105,142 and 62/092,449, the disclosures of which are hereby incorporated by reference in their entireties herein. The discovered devices may be associated with a device ID or other identification, such as by MAC or IP address or subscriber input of an identifying name (e.g., Michael's tablet). The capabilities, services, entitlements and other information regarding capabilities of the device, purchased subscriptions, authorizations and the like may be collected to facilitate identifying the devices and/or the NFV amenable to it (e.g., some NFVs may be application to some devices and not others). The service discovery 60, 62 may be performed in the background or automatically in a manner transparent to the subscriber so as to ameliorate complexity and user interaction. Optionally, the routers, etc. connected directly to or in the paths of the devices (e.g., intermediary routers) may also be discovered or otherwise identified, particularly if the manipulation thereof is necessary to implement one or more of the desired NFVs.

An NFV design process 64 may be performed in order to select the NFVs relevant to each of the discovered devices or data flows from multiple devices with common needs. The NFV design process 64 may be performed on a per device basis and/or according to other differentiations, e.g., a device may have multiple IP addresses such that NFVs may be selected for each IP address or a device may support multiple services/service flows such that NFVs may be selected for each. FIG. 5 illustrates an NFV portal 68 in accordance with one non-limiting aspect of the present invention. The NFV portal 68 may be a webpage or other interface hosted by the MSO and operable with the virtual platform 12 to facilitate identifying the discovered devices and designing the NFVs operable for association therewith. Access to the NFV portal 68 may be restricted to authenticated or registered users, such as by requiring a username and password combination, token or other construct to be provided in order to associate particular NFVs with the devices. The restricted access may be beneficial in limiting children or other unauthorized users from manipulating operations of the home network or thwarting desired NFV implemented restrictions, e.g., parental controls, firewalls, etc.

The NFV portal 68 may include a listing of discovered devices 70, a set of defined users or other groupings such as a group of applications, or other future groupings, and a listing of available NFVs 72. The NFVs may be associated with each device 68 (or other identifiers for signaling amendable to the completed NFV, such as service flows, grouping, applications, etc.) in a drag-and-drop manner whereby a user may click on the desired NFV and drag it to a menu 74, 76, 78 of the desired device. The user may identify the appropriate device according to the device ID and/or the user may be enabled to manually manipulate the device ID to a more descriptive representation, e.g., it may be beneficial to list the device ID manually as “Michael's tablet” instead of listing the Mac/IP address associated therewith. Similarly, multiple sections (not shown) may be included for certain device menus 74, 76, 78 if the corresponding device supports multiple services/service flows or otherwise is amenable to applying NFVs to differentiable packets depending on their associated use/address. In the event certain NFVs are unavailable to particular devices, the corresponding NFVs may be removed from the listing or otherwise prevented from being dragged to the corresponding device, e.g., the user may be required to click on the device menu 74, 76, 78 before dragging one of the NFVs thereto such that any unavailable NFVs may be removed or deemphasized within the NFV listing.

The NFV portal 68 may include additional customizations or other variables to further define selection of that NFVs desired for each device. This may include altering the device menus 74, 76, 78 to include additional sections (not shown) to differentiate between upstream and downstream communications, e.g., NFVs may be applied to the upstream communications but not similarly desired for downstream communications (the user may agree to packet inspection or upstream traveling messages but not for downstream traveling messages). Further customizations may include generating different profiles for a device according to a user thereof, a time of day or other identifying feature, e.g., parental controls may be selectively engaged depending on whether an adult or child is using device and/or whether an adult or child is within the home. The devices within the home may collect and perform analytics on various events, data or information associated with the operation thereof such that this information may be utilized to facilitate selecting when to implement certain profiles and/or the parameters used to automatically differentiate which NFV design are to be implemented for a particular device (e.g., different profiles for different analytics).

The NFV portal 68 may facilitate selection and association of the NFVs with the device menus 74, 76, 78 through the drag-and-drop process or other processes sufficient to enable the customizations contemplated herein without overburdening the home network administrator/subscriber. The NFV portal 68 may include a description or link to additional information for the operations performed by each of the NFVs to help the home network administrate differentiate the NFVs. The NFV portal 68 may include suggested or recommended NFVs for one or more of the devices within a predefined selection menu or listing (not shown), such as to enable the user to drag-and-dropped one of the predefined recommendations to the device listing 70 whereby the related NFV(s) would be automatically associated with the corresponding device without the user having to select each NFV. The use of predefined, recommendations may be particularly beneficial for home network administrators lacking technical understanding regarding the nature operations performed by the corresponding NFV.

The NFV(s) associated with particular devices, such as during a prior NFV design process or through selection of a recommended NFV configuration, may be easily removed by dragging and dropping or deleting the corresponding NFV from the appropriate device listing 68. The ability to remove, add or otherwise alter the NFV designed for a particular device may be beneficial in allowing the home network operator to re-program or to otherwise perform sophisticated operations necessary to implementing the desired changes with a simple drag-and-drop, i.e., the user, particularly one unaware of certain firewall restrictions, may select a particular firewall NFV and thereafter determine it to be unsuitability to its purposes whereby it can be easily changed through the NFV portal in a single operation. The NFV portal 68 may list historical NFV designs or other prior configurations in a menu (not shown) to further ease burdens on the home network administrator, e.g., a default listing may be selected to return the home network 18 to a default configuration or the user may set a vacation profile when traveling and a normal profile when home.

The NFV design process 64 may include associating a chain of events for the NFVs associated with a particular device listing 74, 76, 78. The chain of events may specify an order or sequence in which each NFV is to be performed. FIG. 2 illustrates the NFVs being performed sequentially where a first NFV occurs before a second NFV, however, the NFVs may be implemented in any order to achieve certain/different results. The NFV portal 68 may facilitate the ordering or chaining of the NFVs according to relative positioning within the device listing 74, 76, 78, e.g., the NFV at an upper end of device listing 74, 76, 78 may occur first with each successive NFV listed thereunder occurring in the corresponding order. The network administrator may rearrange or otherwise adapt the order of the NFVs to suit desired purposes. The virtual platform may also be configured to override user selection or to otherwise rearrange the order, or in some cases add necessary NFVs omitted by the home network administration, depending on the NFV and/or whether particular NFVs may be required in order to enable subsequent NFVs, which may be beneficial in ameliorating the burden on the network administrator to be aware of NFV ordering requirements.

After the NFV is designed for each relevant device, user, application etc., the virtual platform 12 may be configured to facilitate implementing the corresponding NFVs. The virtual platform 12 may assess whether to apply certain NFV designs to certain packets depending on information included therein or associated therewith, such as MAC destination/source addresses, IP destination/source addresses, service flow identifiers, VXLAN identifiers, VLAN identifiers, IPv6 flow identifiers, or other information suitable to determining the NFV design appropriate for the corresponding packets, such as an NFV identifier unique to particular NFV chains/designs (multiple devices may be associated with the same NFV identifier if the same NFVs are to be used in the same order). The virtual platform 12 may determine the appropriate NFVs through inspection of the transmitted packets, such as by inspecting the corresponding headers and/or payloads or through other mechanisms, such as a packet or other identifier associated with a particular packet stream or added thereto (NFV identifier) independently of the packets so as to ameliorate any privacy concerns with inspecting packet information.

One contemplated process for upstream transmissions may include a device instigating a transmission 90 of upstream packets to the edge router, whereupon the edge router may instigate a subsequent transmission 92 to the virtual platform 12 or to another device in the home network 20. The edge router 18 may determine the appropriate NFV design and/or perform the NFVs according to instructions provided by the virtual platform 12 in the event the packets are not to be forwarded thereto. The virtual platform 12 may perform an NFV identification process 94 when the packets are forwarded thereto in order to determine the desired NFV design. The NFV identification process 94 may be performed prior to or upon receipt of the packets as emitted from the device, such as by the device including an NFV identifier or the virtual platform 12 determining the desired NFV design from information normally included within the packet, i.e., without requiring the device to provide the NFV identifier or to provide any information intended to identify the desired NFV design. An NFV process 96 may then be performed to implement the virtualizations of the desired NFVs according to the identified NFV design prior to a subsequent transmission 98 of the NFV modified packets.

Another contemplated process for upstream transmissions may include the device instigating a transmission 102 of upstream packet to the edge router 18 whereupon the edger router 18 performs an identification process 104 to determine the desired NFV design. The use of the edge router to perform the identification may be beneficial in allowing the edge router 18 to add the NFV identifier to a subsequent transmission 106 of the packets, optionally without otherwise manipulating the packets, so as to remove the identification responsibilities form the virtual platform 12 and/or to prevent the virtual platform 12 from having to inspect packets or their contents. The virtual platform 12 may thereafter perform a NFV process 108 according to the identified NFV design prior to a subsequent transmission 110 of the modified packets. The NFVs or virtualization may include control plane NFV features that look at packet headers and enforce policy on a network, e.g. where packets are routed or stopped (firewall), QoS, bandwidth, etc., and/or data plane NFV features that may be inserted in the traffic forwarding path and affect the payload of the traffic, e.g., changing IPv4/I Pv6 addresses to IPv6/I Pv4 addresses.

One contemplated process for downstream transmissions may include the server 22 instigating a transmission 114 of downstream packets to the virtual platform 12 whereupon the virtual platform 12 performs an NFV identification process 116 to determine whether an NFV design is associated therewith. As with the upstream transmissions, the originator of the transmission (the server) may include an NFV identifier with the transmission 114 and/or the virtual platform 12 may determine the desired NFV design as a function of other information included within the packets, i.e., without requiring the originator to identify the NFV design. The virtual platform 12 may thereafter perform a NFV process 118 according to the identified NFV design prior to a subsequent transmission 120, 122 of the modified packets. As with the upstream packets, the downstream packets may be similarly modified according to control plane NFV features where routing or other network policies may be enforced and/or according to data plane NFV features where payloads or other information included within the downstream packets are modified, inspected, confirmed etc.

FIG. 6 illustrates a messaging diagram for a method of facilitating NFV in accordance with one non-limiting aspect of the present invention. The present invention contemplates the NFV being executed on the home gateway itself, as described above, and/or on the virtual platform 12 can exist at the ISP cloud, on the home gateway, or a combination of both. FIG. 6 illustrates a service discovery process 130, 130 to facilitating and NFV design process 134 in a manner similar to that described above whereafter the virtual platform 12 provides NFV instructions 136 to the edge router 18. The edge router 18 can not only identify packets or data streams or devices/users/applications, but also effect the NFV before that traffic is sent to the ISP. The NFV instructions 136 may be sufficient to enable the edge router 18 to perform the desired NFV locally instead of at the virtual platform 12 and without requiring the home network administrator to program the edge router 18. Upon receipt of upstream packets 138, the edge router 18 may perform an NFV process 140 according to the NFV design 134 and thereafter transmit 142 the modified packets to the server 22 without requiring further NFV modifications. Optionally, upon receipt of additional upstream packets 146, the edge router 18 may perform a partial NFV process 148 whereby the edge router 18 performs some of the NFV specified in the NFV design 134. The edge router 18 may then transmit 150 partial NFV packets to the virtual platform 12 whereupon the virtual platform 12 performs a partial NFV process 152 to complete the remaining NFVs prior to a subsequent upstream transport 154 of the fully modified NFV packets. While not shown, similar processing may be perform for downstream packets whereby the edge router 18 may perform all or a portion of the NFVs designed for downstream packets according to instructions received from the virtual platform 12.

As supported above, one non-limiting aspect of the present invention contemplates facilitating NFV when a subscriber logons to an MSO portal (website) that reflects that particular subscriber's home environment; devices, users and MSO services/policies that can be applied to those devices and/or users. The devices can be automatically discovered using mechanisms such as LLDP, mDNS, UPnP, DHCP-fingerprinting or other such known methods. Additionally, the subscriber (or a user at the subscriber's premise) can manually enter devices into the portal such that the portal reflects all the devices. Zones may be created by associating one or more devices to a service or policy by some action such as dragging a policy to a device. Users, people that use MSO services behind the subscriber's home gateway, can also be identified on the portal, each with their own login/password credentials. Similarly, an application can be listed on the portal, being identified by some means such as TCP/UDP port number, DPI , or other means. A device and/or a user and/or an application can be paired to a service or policy to create a zone. Most traffic will egress past the home gateway, to the MSO network and onto a site or service in the Internet. The users, applications and devices within a zone can now have a unique marking applied to the traffic to indicate to the MSO, the services that are required. That marking can be a predefined map that indicates one or more VNFs (Virtual Network Function) in the MSO cloud that are chained together so as to enable an Orchestrator at the MSO to arrange the subscriber's data flow.

The markings for the NFV selection mapping could be accomplished in several ways; a VLAN tag could be added to the Ethernet frame before that frame is encapsulated inside a VXLAN tunnel that connects the Home Gateway to the MSO cloud, such as. Since the VXLAN tunnel has unique tunnel endpoints (IP Addresses defined by the MSO), and since the VLAN information is preserved along the path to the MSO cloud, the MSO knows which subscriber the data flow comes from and the VLAN information indicates which service or services should be applied to that data flow. Hence, every subscriber could theoretically over 16 million subscribers in a single domain. Once the subscriber's traffic arrives to the MSO tunnel terminator, a B/OSS systems identifies the subscriber and authorize the service(s) needed for that data flow. The Orchestrator, part of the Virtual platform, detects which VNFs are needed and available and with the SDN controller, directs the traffic through the VNFs. Those VNFs might be located in the MSO's data center which has massive capacity of servers that can dynamically have Virtual Machines ‘spun up’ as needed and VNFs created on those virtual machines to elastically cover the rise and fall of demand throughout the hours and days.

The mapping could also use multiple VXLAN tunnels, one tunnel for each ‘service’. Again, since each of these tunnels have a unique identifier, the overall tunnel identifies the subscriber and the individual service tunnels inside the overall tunnel indicate the VNFs (services or policies) to be applied. Alternatively, devices and/or users can be dragged to services/policies on the portal instead of devices/users dragged to the service/policy. Either way, a zone may be created. These zones may be predetermined (with their tagged values) by the MSO before they are made available to the MSO portal. If a subscriber logs onto the portal, using unique credentials that identify permission to make changes, user and devices can be placed into zones. The subscriber may place the children's PC and two tablets into the Parental Control service. The MAC addresses (discovered by the service discovery mechanisms or manually entered) are associated with the device. The user could be authenticated by logging into the portal to establish an authorized data flow from a particular device. This could prevent a child from using a parents tablet and bypassing Parental Control features on the child's tablet.

HIPnet provides IPv6 support in the home, and service discovery and CER-ID. VXLAN tunnels provide rich layer-2 information, such as MAC addresses to the MSO. The present invention contemplates providing a portal that allows semi-custom features to be applied by the subscriber, dynamically, and utilize high horsepower servers to support hardware accelerators for example for services such as DPI (Deep Packet Inspection). This idea creates zones and maps data flows into zones, which is key to applying services. Analytics can then reveal traffic patterns and can be used to create new services targeted to a group of subscribers that has a high likelihood of success and monetization. The present invention contemplates pushing policies to the home gateway as an alternate idea of hosting all services in the MSO cloud. The MSOs now have unique opportunities for other new services such as controlling or optimizing home wireless remotely (Wi-Fi, Bluetooth, ZigBee, etc. While either SDN or NFV can be used by itself, there is synergy in combining the two technologies. Taken in combination, NFV provides the ‘what’ (virtualization architecture) and SDN provides the ‘how’ (APIs and control protocols) to enable service providers to embrace network virtualization.

While exemplary embodiments are described above, it is not intended that these embodiments describe all possible forms of the invention. Rather, the words used in the specification are words of description rather than limitation, and it is understood that various changes may be made without departing from the spirit and scope of the invention. Additionally, the features of various implementing embodiments may be combined to form further embodiments of the invention.

Claims

1. A non-transitory computer-readable medium having a plurality of non-transitory instructions operable with a virtual platform to facilitate network function virtualization (NFV) for a plurality of devices connected to a home network, the non-transitory instructions being sufficient for:

performing a first network function virtualization (NFV) on a first plurality of packets associated with a first device of the plurality of devices, the first plurality of packets being communicated between a first server and the first device via the virtual platform; and

performing a second network function virtualization (NFV) on a second plurality of packets associated with a second device of the plurality of devices, the second plurality of packets being communicated between a second server and the second device via the virtual platform.

2. The non-transitory computer-readable medium of claim 1 further comprising non-transitory instructions sufficient for determining the first and second NFVs to include one or more of a plurality of virtualizations listed in a NFV portal for user selection, the NFV portal being hosted on a server operating independently of an edge router of the home network.

3. The non-transitory computer-readable medium of claim 2 further comprising non-transitory instructions sufficient for:

listing the plurality of virtualizations to include at least a first virtualization, a second virtualization and a third virtualization;

determining based on the user input the first NFV to include the first virtualization and the second virtualization; and

determining based on the user input the second NFV to include the first virtualization and the third virtualization.

4. The non-transitory computer-readable medium of claim 3 further comprising non-transitory instructions sufficient for performing the first NFV in a first sequence whereby the first plurality of packets are processed at the virtual platform according to the first virtualization and then the second virtualization.

5. The non-transitory computer-readable medium of claim 4 further comprising non-transitory instructions sufficient for performing the second NFV in a second sequence whereby the second plurality of packets are processed at the virtual platform according to the third virtualization and then the first virtualization.

6. The non-transitory computer-readable medium of claim 5 further comprising non-transitory instructions sufficient for simultaneously performing the first and second NFV at the virtual platform such that at least a portion of the first and second plurality of packets are simultaneously communicated from the virtual platform to the home network following the corresponding first and second NFV.

7. The non-transitory computer-readable medium of claim 2 further comprising non-transitory instructions sufficient for listing the plurality of virtualizations to include:

a Network Address Translation (NAT) virtualization;

a firewall virtualization;

a routing and forwarding virtualization;

a Virtual Private Networks (VPNs) virtualization;

a Dynamic Host Configuration Protocol (DHCP) and Domain Name Service (DNS) virtualization;

a Deep Packet Inspection virtualization;

a Denial of Service protection virtualization; and

a Parental Controls virtualization.

8. The non-transitory computer-readable medium of claim 1 further comprising non-transitory instructions sufficient for:

configuring the first NFV to include performing at least a first virtualization and a second virtualization at the virtual platform; and

configuring the second NFV to include performing at least the first virtualization, the second virtualization and a third virtualization at the virtual platform.

9. The non-transitory computer-readable medium of claim 8 further comprising non-transitory instructions sufficient for adding a first identifier to the first plurality of packets when transmitted from the virtual platform to the home network and adding a second identifier to the second plurality of packets when transmitted from the virtual platform to the home network, the first and second identifiers being operable with an edge router of the home network to facilitate transmission of the corresponding first and second plurality of packets over the home network to the corresponding first and second devices.

10. The non-transitory computer-readable medium of claim 1 further comprising non-transitory instructions sufficient for performing the first NFV on the first plurality of packets at the virtual platform following transmission from an edge router of the home network.

11. The non-transitory computer-readable medium of claim 10 further comprising non-transitory instructions sufficient for determining the first NFV to be performed on the first plurality of packets according to a first identifier transmitted therewith from the edge router, the first identifier being different from a second identifier associated with the second NFV and being associated with a first plurality of virtualizations, the first plurality of virtualizations specifying processing to be performed at the virtual platform on the first plurality of packets in order to perform the first NFV.

12. The non-transitory computer-readable medium of claim 11 further comprising non-transitory instructions sufficient for determining the first plurality of virtualizations from a virtualization table, the virtualization table cross-referencing at least the first identifier with the first plurality of virtualization and the second identifier with a second plurality of virtualizations.

13. The non-transitory computer-readable medium of claim 12 further comprising non-transitory instructions sufficient for generating the virtualization table such that the second plurality of virtualizations include one or more virtualizations different from the first plurality of virtualizations.

14. A non-transitory computer-readable medium having a plurality of non-transitory instructions operable with a virtual platform to facilitate network function virtualization (NFV) for a home network, the non-transitory instructions being sufficient for:

determining a first NFV design for a device connected to the home network; and

performing a first plurality of network function virtualizations (NFVs) on a first plurality of packets prior to being transmitted from outside of the home network to the device, the first plurality of NFVs being specified in the first NFV design.

15. The non-transitory computer-readable medium of claim 14 further comprising non-transitory instructions sufficient for:

determining a second NFV design for the device; and

performing a second plurality of NFVs on a second plurality of packets transmitted from the device after being transmitted from the home network, the second plurality of NFVs being specified in the second NFV design and different at least in part from the first plurality of NFVs.

16. The non-transitory computer-readable medium of claim 15 further comprising non-transitory instructions sufficient for determining the first and second plurality of NFVs for the first and second NFV designs as a function of user inputs to an NFV design portal, including determining one or more of the first and second plurality of NFVs as a function of a user dragging and dropping one or more NFV icons from a listing of available NFVs to a menu associated with the device.

17. The non-transitory computer-readable medium of claim 15 further comprising non-transitory instructions sufficient for selecting the first NFV design from a plurality of NFV designs based on a first identifier being included within the first plurality of packets.

18. The non-transitory computer-readable medium of claim 17 further comprising non-transitory instructions sufficient for selecting the second NFV design from the plurality of NFV designs based on a second identifier different from the first identifier being included within the second plurality of packets.

19. The non-transitory computer-readable medium of claim 15 further comprising non-transitory instructions sufficient for selecting the first and second NFV designs from a plurality of NFV designs based on an address included in each of the first and second plurality of packets.

20. A system for facilitating network function virtualization's (NFVs) for a home network comprising:

a portal including a listing of devices connected to the home network and a listing of available NFVs, the portal enabling a user to create NFV designs for each of the devices according to user inputs thereto; and

a virtual platform having a plurality of servers configured to implement each of the NFVs associated with the listing of available NFVs, the virtual platform being configured to process packets communicated to/from the devices according to the NFVs specified in the NFV design for the corresponding device.