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 
       [0001]    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 
       [0002]    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 
       [0003]    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 
         [0004]    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. 
         [0005]    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 
         [0006]      FIG. 1  illustrates a network function virtualization (NFV) system in accordance with one non-limiting aspect of the present invention. 
           [0007]      FIG. 2  illustrates operation a virtual platform in accordance with one non-limiting aspect of the present invention. 
           [0008]      FIG. 3  illustrates zoning of a home network in accordance with one non-limiting aspect of the present invention. 
           [0009]      FIG. 4  illustrates a messaging diagram for a method of facilitating NFV in accordance with one non-limiting aspect of the present invention. 
           [0010]      FIG. 5  illustrates an NFV portal in accordance with one non-limiting aspect of the present invention. 
           [0011]      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 
       [0012]    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. 
         [0013]      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. 
         [0014]    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. 
         [0015]    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. 
         [0016]      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. 
         [0017]    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. 
         [0018]    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. 
         [0019]      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. 
         [0020]    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. 
         [0021]    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&#39;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. 
         [0022]    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.       
 
         [0028]    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.       
 
         [0033]    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.       
 
         [0036]    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&#39;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. 
         [0037]    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&#39;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. 
         [0038]      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). 
         [0039]    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&#39;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. 
         [0040]    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. 
         [0041]    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&#39;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. 
         [0042]    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). 
         [0043]    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. 
         [0044]    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. 
         [0045]    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. 
         [0046]    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. 
         [0047]    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. 
         [0048]    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. 
         [0049]    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. 
         [0050]      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 . 
         [0051]    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&#39;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&#39;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&#39;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&#39;s data flow. 
         [0052]    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&#39;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&#39;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. 
         [0053]    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&#39;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&#39;s tablet. 
         [0054]    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. 
         [0055]    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.