In the previous two installments of this series on SDN and NFV I
discussed the virtualization and configuration of communications
functionalities; this installment will deal with their placement. I call this
aspect geography, and this time use the term in its most literal sense – where
geographically a given function should be physically located.
Note that this aspect of a network function is independent of the previous ones. Even a nonvirtualized function implemented entirely in dedicated hardware can still be placed in various places along the communications path. Of course, most functions do have traditional locations - e.g., a firewall is generally placed at the customer network's ingress point, and a pseudowire interworking function is placed at the Provider Edge (PE). But, there is some flexibility in these placements. When the service provider provides the firewall function, it does so by moving this function from the customer premises to the service provider's. If the customer maintains the pseudowire the IWF is placed at the customer premises rather than at the PE.
SDN and NFV herald yet more flexibility. Virtualization of networking functionalities may expose many placement options by offering numerous locations with the resources required to run the Virtual Network Function (VNF). And SDN enables dissociating protocols from their conventional locations; e.g., routing protocols can be removed from routers and run on servers in remote datacenters instead. CPRI goes even further by moving all eNodeB processing (except the antenna, mixer, and A/D) to dedicated hardware at a remote location.
In principle, all network
functions can be virtualized. This statement derives from the computational
universality (technically the Turing completeness) of CPUs. In practice, however, virtualization
of certain functions is not practical (at least not at reasonably high data-rates). For example, while it is straightforward to perform L2 or L3 forwarding at Gigabit speeds on a CPU,
at 10G rates utilizing dedicated hardware is more cost effective, and at 100G
there is presently no option for virtualization. Similarly, certain intensive
operations are more effectively left in dedicated hardware, for example
bandwidth shaping, high-rate CCs for protection switching, and encryption.
What about the geographic positioning of network functions? Can all
network functions be, in principle, arbitrarily positioned? Should they be ?
The three most important factors in determining the desirability of a
property are location, location, location.
-
incorrectly attributed to Harold
Samuel, UK realtor
A residence that perfectly suits your needs can’t
usually be moved it to the desired location. The same is true for certain
networking functionalities. Not every function can be placed anywhere there are available resources. And even for those that can be placed anywhere, there are many reasons to select specific locations.
As an obvious example consider loopback
functionality. Loopback diagnostic testing enables a remote administrator to verify connectivity to and from a remote site. Moving this function to a remote datacenter makes no sense at all! The same can be said for many security functionalities, such as encryption and Denial of Service (DoS) attack blocking. Moving encryption to the other side of an access network leaves unencrypted traffic exposed to all with access to that network, and conversely, blocking malicious traffic at the other side leaves the door open to attackers with access to the network.
Deep Packet Inspection (DPI) provides a slightly less obvious example. Moving a DPI function from the place where it is needed necessitates sending the packets to be inspected to a remote DPI engine, resulting in additional bandwidth consumption and increased processing delay. If the bandwidth is unavailable or too expensive, or if the added delay exceeds the budget for the applications involved, then DPI needs to remain in situ even if computational resources are less expensive elsewhere.
Another placement constraint arises from regulatory issues. For example, certain databases must not be moved across commercial or jurisdictional boundaries. Traffic crossing certain borders may subject parties to taxation. Certain on-line activities may be legal in some jurisdictions but not in others. Requirements for lawful interception may also influence placement decisions.
On the other hand many functions can be placed in many different locations. The most credible cases are routing and path computation, as well as billing/charging. Other innovative placements are being extolled in the press and heatedly discussed in the forums. The security and privacy implications of such placements are only recently receiving attention.
When functions can be placed in many geographical locations, the final placement decision is usually based on economics. Service provider Points of Presence (POPs) and datacenters may be attractive due to the ability to exploit economies of
scale. Real estate expenditures are minimized by colocating as many functions aspossible. Cooling costs may be minimized by running functions in riverside datacenters with water cooling. Placing multiple instances of a function in the same datacenter can hugely simplify management and maintenance.
In fact, many people equate NFV with moving all nontrivial control functionality to datacenters leaving no intelligence in the network. The CloudNFV initiative is based on the tenet that it is most efficient to run VNFs as SaaS. On the other hand RAD believes in Distributed NFV (D-NFV) wherein each function is placed at the position in the network where it can best fulfill its function. That position may be at a CPE, or an aggregation point, or in the network core, or in a data-center.
Another issue complicating placement decisions is function chaining. In many cases there are multiple functions that need to be performed on packets somewhere along the end-to-end path, with restrictions on the order in which these functions need to be performed. These functions may include packet shaping, packet remarking, NAT, intrusion detection, and tunnel encapsulation. We certainly wouldn't want to send a packet to a remote datacenter for intrusion detection, return it for shaping, and then send it back to the datacenter for NAT.
Optimization of function chaining turns out to be more complex than that carried out by a Path Computation Element (PCE). The latter need only find acceptable paths through equivalent routers, while the former needs to handle much more complex paths and constraints.
As an abstract example, imagine that functions A, B, C, D, and E all need to be performed on every packet belonging to a service before final delivery. Function A must be performed before either B or C; B and C can be performed in either order but must be performed before C or D; and E must be the last function performed before delivery. Imagine further that in the network there are numerous devices that are able to perform these functions, but not all devices can perform all functions. Furthermore, the services have delay cutoffs, bandwidth should not be needlessly wasted, and resource loading should be equalized in order to avoid bottlenecks and potential points of failure. Finally, the computation of the chaining order needs to be performed upon intializing a new service, and while changing the service chaining configuration of an existing service is possible, it should be avoided due to the negative impact on service quality.
How does the function chain orchestrator determine the optimal placement of each VNF? I'll discuss that in the next installment.
Y(J)S
