U.S. patent application number 14/788684 was filed with the patent office on 2016-01-07 for network function virtualization (nfv).
The applicant listed for this patent is Cable Television Laboratories, Inc.. Invention is credited to John Berg, Christopher Donley, Michael Kloberdans.
Application Number | 20160006696 14/788684 |
Document ID | / |
Family ID | 55017834 |
Filed Date | 2016-01-07 |
United States Patent
Application |
20160006696 |
Kind Code |
A1 |
Donley; Christopher ; et
al. |
January 7, 2016 |
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.
Inventors: |
Donley; Christopher;
(Broomfield, CO) ; Berg; John; (Arvada, CO)
; Kloberdans; Michael; (Brighton, CO) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Cable Television Laboratories, Inc. |
Louisville |
CO |
US |
|
|
Family ID: |
55017834 |
Appl. No.: |
14/788684 |
Filed: |
June 30, 2015 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
62019473 |
Jul 1, 2014 |
|
|
|
Current U.S.
Class: |
709/223 |
Current CPC
Class: |
H04L 45/60 20130101;
H04L 63/0236 20130101; H04L 41/5054 20130101; H04L 61/2507
20130101; H04L 63/0272 20130101; H04L 41/5058 20130101; H04L 67/10
20130101; H04L 67/16 20130101; H04L 61/1511 20130101; H04L 61/2015
20130101; H04L 45/586 20130101 |
International
Class: |
H04L 29/06 20060101
H04L029/06; H04L 12/773 20060101 H04L012/773; H04L 29/12 20060101
H04L029/12; H04L 12/24 20060101 H04L012/24; H04L 12/713 20060101
H04L012/713 |
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.
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.TM. 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'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: [0023] 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. [0024] 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. [0025]
Routing and forwarding, which identifies the optimal paths to send
traffic through the network. [0026] Virtual Private Networks
(VPNs), which provide private connectivity to remote networks such
as corporate offices. [0027] IPv6 transition technologies.
[0028] Likewise, the data plane features may include: [0029]
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. [0030] Deep
Packet Inspection, which looks into packet payloads and helps with
Denial of Service and Parental Controls. [0031] Denial of Service
protection, which looks for traffic anomalies and block unwanted
traffic streams. [0032] 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: [0034] 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). [0035] 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'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'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'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'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'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.
[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'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.
[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'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.
[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.
* * * * *