Patent Application
20160006696
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.
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.
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.
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.
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.
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:
Likewise, the data plane features may include:
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:
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.
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.
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.
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.
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.
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.
| Number | Date | Country | |
|---|---|---|---|
| 62019473 | Jul 2014 | US |
