So, these are the links that we're currently active on. I've been snapping these videos and actually embedding them in my presentation because these links go out of date after a while sometimes and I didn't want to Q1 off in class and then have it not be available. So these are the links for the following three. So, network functions virtualization allows network operators to dynamically place or move networking capability as usage demands change. Here are first one. Welcome to this Alan talks tech presentation on network functions virtualization or NFV. So, exactly, what is Network Functions Virtualization? Well, a quick warning, it could be a little bit confusing, as it came out of the software defined networking group or SDN group. However, they would like to emphasize that they see network functions virtualization as highly complementary to software defined networking. These topics are mutually beneficial but not dependent on each other. Network functions can be virtualized and deployed without an SDN being required and vice-versa. So, from an operator's point of view today, operating, installing, and maintaining equipment to the enterprise site can be a rather complex affair. There are many different products that they may be responsible for maintaining firewalls, routers, server's, load balances, switches, and media servers. Overall, from a telecom operators point of view, this appears to be rather inflexible, costly, high power requirements, each device has its own separate power supply and a number of truck rolls may be required. That is a number of people may be sent out on site and to install, configure, and maintain this overall complex environment. So, they would like to reduce this complexity. One way of doing this, would be to use a standard X86 architecture. For example, a blade server. By using a blade server we would be using standard hardware which would give us a less complex environment giving us flexibility and reduce power consumption, lower CapEx, lower OpEx, would be able to test new applications with a lower risk, reduce time to market and of course open up the market to many other software suppliers. But I think moving forwards, most operators, most enterprise users will prefer to use a virtual environment. Using virtualization we could still use a standard X86 architecture, a single server but running on top of that X86 platform will install a hypervisor. On top of the hypervisor we can install all the virtual machines, each virtual machine associated with its own independent operating system. In turn, running the media server, the router, the switch, the firewall, the web server or the load balancer. Again, this gives us that standard hardware architecture which is less complex, very flexible with reduced power consumption, lower CapEx, lower OpEx. Again, so much more flexibility due to the virtual environment to test new applications with a low risk reducing our time to market and of course again opening up that market to many other software suppliers. So, who's behind this initiative? Well, it all began with the SDN and OpenFlow World Congress in Darmstadt Germany last October. That was October the 22nd to the 24th of 2012. Since then, a new committee has been set up under the ETSI banner, in January of 2013. Initially though in Darmstadt, there were several operators that added together and produced a white paper outlining their ideas for Network Functions Virtualization. Since that time, many other operator's, network equipment manufacturers, and software developers have joined the group. Such a situation could take place if traditional networks were used to control cars. So, where's the problem? Let's rewind the recording to see what actually happened. This car belongs to a new generation of driverless vehicles where when integrated computer connects to the network in order for the car to drive autonomously. Autonomous cars are an example of a new type of application where network response time becomes critical. Traditional network architecture where the application data has to pass through several network nodes may cause significant delays. The problem may become even more serious when the network is also congested with other requests. For example, when users in the same location or using applications such as Facebook or YouTube, a virtual network can adjust its virtual architecture dynamically. So that applications are prioritized why they're important and virtual machines are allocated accordingly. Network function virtualization makes it possible for each node in the network topology do become a micro data center, able to host various applications. In this way, latency sensitive applications such as those installed in autonomous cars don't have to be hosted in a distant data center. Instead they can be as close to the user as possible, as a result the communication path between the user and the application become shorter and the application server latency can be reduced to one millisecond. Comarch OSS is a modern solution that helps your network to compare network queries intelligently and automatically prioritizes them based on their importance. Thus the decisions about where the application should be hosted and how many virtual machines it needs to run smoothly or also automated. Thanks to network virtualization and Comarch OSS, our story can have a happy ending, where each user can connect to the network quickly and safely. Comarch- prepare today for the challenges of tomorrow. In this lesson we'll start a discussion on the near future of SDN. And in particular, we'll talk about what SDN has to say about network, compute and storage more broadly. Which is coming to be known as a concept called Network Functions Virtualization or NFV. One of the issues that network operators faces, that middle boxes are pervasive. And an interesting question to study is what SDN has to say about middle boxes. We spent a lot of attention focusing on how SDN can affect the data plane as far as forwarding is concerned but networks have firewalls, intrusion detection systems, VPN gateways, WAN optimizers and a whole bunch of middle boxes that could conceivably be controlled from a logically centralized point. SDN of course promises centralized management of the foreign parts of the data plane but a reasonable question is whether it can also be a unifying framework for a more general set of functions. Network Functions Virtualization combines foreign devices and middle boxes into a common control framework. Its promise is to enable network operators to implement network policy without having to worry about the nitty-gritty details of how it's actually implemented. Two implementation details we'd like to abstract are placement, in other words where to place these functions inside the network and steering. Which is once we place these middle box functions how we should route or direct traffic flows through the network so that they pass through the appropriate set of elements or functions before they eventually reach their destination. The problems of placement and steering are incredibly hard. We need to figure out a way to map traffic flows and demands to both the available network resources or the paths and the available processing capacity of middle boxes. It's like an extremely hard traffic engineering problem because not only do you have to consider the available resources of the network but you also have to consider the available processing capacity of boxes that are sitting in the network and which by the way might be virtual. So you have the option not only of moving the traffic to existing middle boxes but also the option of moving middle boxes to where the traffic is. So solving these problems just by themselves are extremely challenging but we also need a unified abstraction for expressing the nature of the type of solution that we're looking for. In other words we need a unified abstraction for control of a network forwarding, data and storage. One could call this problem more generally middle box orchestration. And a system that we've been working on called Slick, seeks to solve some of these problems. One could broadly classify this into the set of problems that NFV or Network Functions Virtualization is really trying to solve. The idea is that you want to augment your SDN controller so that not only is it installing flow table entries or things that affect forwarding behavior but also middle box style elements or code that could perform more complex operations on the traffic as it passes through the network. So the controller is ultimately responsible for installing and configuring this code or what we might call elements, steering the traffic through these elements and also handling any callbacks that the elements themselves might generate. We want these elements so the code that's representing middle box functions that could run in the network to be able to implement arbitrary code. For that we expose a common API through which a controller can install code and also interact and configure existing elements. A controller might then be able to use, manifest that physical network devices used to describe the available resources, to figure out the appropriate places to place these elements or functions at the appropriate physical locations inside the network. A slick application runs at the controller and implement some kind of network policy. That network policy determines which element or sets of elements should run on which portions of floor space and how to react to various changes in network conditions. It does not specify where the element should be placed or how the traffic should be steered or routed through those elements. Those details are handled by the runtime. The controller manages and configures the network of middle boxes. It implements resource discovery much like a standard open flow controller would implement topology discovery except now we're discovering other types of resources as well. In addition to installing or removing flow table entries, this controller also deploys or removes elements that run on machines through the network. It also ensures availability of these elements in the face of failures. The controller ultimately implements whatever policy that the application specifies, by automating element placement and steering traffic through the elements once they've been placed in the network. To do so, it uses online algorithms to ensure that resources are allocated efficiently and the traffic flows see good performance as the process by elements in the network. Let's take a look at a quick example of an application with this type of dynamic placement of middle boxes or elements. And network operator might for example want to inspect all DNS traffic with a DPI device and then if a suspicious lookup takes place redirect that traffic to some kind of traffic scrubber. This type of application involves a number of moving parts. One involves placement. Where should we place the DPI device? Another is steering. Once we've placed the DPI devices or devices we need to redirect DNS flows through those DPI devices that we've placed. Finally we have an element of triggering. Whereby if a particular event such as a suspicious lookup is detected by a middle box we want that middle box to then send a callback or a trigger to the network controller that then updates flow tables to redirect network traffic to the appropriate locations. Whatever solution we come up with we want to minimize the implementation footprint and also enable optimization for bandwidth, latency and network resources. Let's take a look at the problem of placement in a bit more detail. At a high level we're given a specification of different parts of floor space, it should map to different sequences of elements. In other words, we might say that all port 80 traffic should be subject to a DPI element followed by a load balancer app, and we might have a collection of these specifications. Now our task is to place the sequence of elements or element graph inside the network such that resource utilization is minimized. We might consider minimizing the number of locations where we place these elements, minimizing the bandwidth utilization of placing these elements or minimizing the latency of the traffic flows while implementing a particular policy. Let's say that we have an element graph such as the one shown at the top of this figure, E1 E2 and E3. And we'd like a particular set of traffic flows to be passed through this element sequence. We could place those elements all in one physical middle box but even if we did that we have the decision of where to put it in the network. We could put it closer to the ingress or closer to the egress or somewhere in the middle. Placing the elements in the wrong place can actually have some pretty dire consequences for the traffic as it's flowing through the network. For example, if we put them in the wrong place we might have cases where traffic flows boomerang through different parts of the network causing higher bandwidth utilization, more latency or more utilization of precious switch resources. So we need to figure out how to place this element graph through the network in ways that avoid these types of problems. Once we've placed the elements we also need to figure out how to steer traffic through the network so that the flows actually pass through the right sequence of elements. Different source destination pairs might be steered through different instances of the same element sequence or element graph. Finding the shortest path is not the only requirement for steering, it also needs to have properties aside from shortest path steering. For example, we might want to make sure that all traffic flows pass through a set of elements in a consistent order. We might want to chain elements or sets of elements in a particular order, we might want to enforce steering of traffic flows through a particular sequence of elements even when routing is asymmetric or we might want the element graph itself to be a symmetric. We also might want some of the steering to be dynamic. In other words, whether a flow passes through a subsequent sequence of elements in the element graph might actually depend on the outcome of processing from an element that's upstream in the graph. Let's take a brief look at dynamic chaining in a little bit more detail. We might want to enable path changes or packet flows based on certain conditions. For example, you might have a state full firewall, it inspects traffic flows with particular that inspects the destination IP address of traffic flows and passes the traffic through either a DPI box on antivirus proxy depending on the destination IP address. In this case the chaining of elements actually depends on the outcome of the first element. We are still in the process of designing runtimes that efficiently place and steer middle boxes for these types of problems. One simple approach is to do an iterative placement and steering, where the network continually monitors link and machine loads and then the case of overloaded elements create new instances of those elements. Subsequently the controller can then steer traffic through those new elements. In summary, i'm still in search of a programming model that unifies network, compute and storage in the context of Middle box placement and network traffic processing. In addition to the programming model, we also need a runtime that can efficiently place these elements in the network and steer traffic to the appropriate instances of the elements once they've been placed. Solving these problems needs both efficient algorithms for placement and steering as well as the proper programming abstractions so that a network operator can simply define policies at a logically centralized controller without having to worry about the details of placement and steering.
