Blog

After a successful and exciting OPNFV Summit last week, you can learn more about IO Visor at the 2nd P4 Workshop by Stanford/ONRC on Wednesday, November 18th. At 3:00pm I’ll discussing how IO Visor and the P4 language are ideally suited for each other in the session, P4 and IO Visor for Building Data Center Infrastructure Components. During this session you’ll see in action a programmable data plane and development tools simplifying the creation and sharing of dynamic “IO modules” for building your data center block by block. These IO modules can be used to create virtual network infrastructure, monitoring tools and security frameworks within your data center. You’ll also learn about eBPF, which enables infrastructure developers to create any in-kernel IO module and load/unload them at runtime, without recompiling or rebooting.

I’m looking forward to meeting all of you all at P4 Workshop this Wednesday.

—
About the author of this post

Continuing from where I left before, in this post we would see some of the major changes in BPF that have happened recently – how it is evolving to be a very stable and accepted in-kernel VM and can probably be the next big thing – in not just filtering but going beyond. From what I observe, the most attractive feature of BPF is its ability to give access to the developers so that they can execute dynamically compiled code within the kernel – in a limited context, but still securely. This itself is a valuable asset.

As we have seen already, the use of BPF is not just limited to filtering out network packets but for seccomp, tracing etc. The eventual step for BPF in such a scenario was to evolve and come out of it’s use in the network filtering world. To improve the architecture and bytecode, lots of additions have been proposed. I started a bit late when I saw Alexei’s patches for kernel version 3.17-rcX. Perhaps, this was the relevant mail by Alexei that got me interested in the upcoming changes. So, here is a summary of what all major changes have occured. We will be seeing each of them in sufficient detail.

Architecture

The classic BPF we discussed in the last post had two 32 bit registers – A and X. All arithmetic operations were supported and performed using these two registers. The newer BPF called extended-BPF or eBPF has ten 64 bit registers and supports arbitary load/stores. It also contains new instructions like BPF_CALL which can be used to call some new kernel-side helper functions. We will look into this in detail a bit later as well. The new eBPF follows calling conventions which are more like modern machines (x86_64). Here is the mapping of the new eBPF registers to x86 registers:

The closeness to the machine ABI also ensures that unnecessary register spilling/copying can be avoided. The R0 register stores the return from the eBPF program and the eBPF program contexts can be loaded through register R1. Earlier, there used to be just two jump targets i.e. either jump to TRUE or FALSE targets. Now, there can be arbitary jump targets – true or fall through. Another aspect of the eBPF instruction set is the ease of use with the in-kernel JIT compiler. eBPF Registers and most instructions are now mapped one-to-one. This makes emitting these eBPF instructions from any external compiler (in userspace) not such a daunting task. Of course, prior to any execution, the generated bytecode is passed through a verifier in the kernel to check its sanity. The verifier in itself is a very interesting and important piece of code and probably story for another day.

Building BPF Programs

From a users perspective, the new eBPF bytecode can now be another headache to generate. But fear not, an LLVM based backend now supports instructions being generated for BPF pseudo-machine type directly. It is being ‘graduated’ from just being an experimental backend and can hit the shelf anytime soon. In the meantime, you can always use this script to setup the BPF supported LLVM yourslef. But, then what next? So, a BPF program (not necessarily just a filter anymore) can be done in two parts – A kernel part (the BPF bytecode which will get loaded in the kernel) and the userspace part (which may, if needed gather data from the kernel part) Currently you can specify a eBPF program in a restricted C like language. For example, here is a program in the restricted C which returns true if the first argument of the input program context is 42.  Nothing fancy :

This C like syntax generates a BPF binary which can then be loaded in the kernel. Here is what it looks like in BPF ‘assembly’ representation as generated by the LLVM backed (supplied with 3.4) :

If you are adventerous enough, you can also probably write complete and valid BPF programs in assembly in a single go – right from your userspace program. I do not know if this is of any use these days. I have done this sometime back for a moderately elaborate trace filtering program though. It is also not effective as well, becasue I think at this point in human history, LLVM can generate assembly better and more efficiently than a human.

What we discussed just now is probably not a relevant program anymore. An example by Alexei here is what is more relevant these days. With the integration of Kprobe with BPF, a BPF program can be run at any valid dynamically instrumentable function in the kernel. So now, we can probably just use pt_regs as the context and get individual register values at each time the probe is hit. As of now, some helper functions are available in BPF as well, which can get the current timestamp. You can have a very cheap tracing tool right there 🙂

BPF Maps

I think one of the most interesting features in this new eBPF is the BPF maps. It looks like an abstract data type – initially a hash-table, but from kernel 3.19 onwards, support for array-maps seems to have been added as well. These bpf_maps can be used to store data generated from a eBPF program being executed. You can see the implementation details in arraymap.c or hashtab.c Lets pause for a while and see some more magic added in eBPF – esp. the BPF syscall which forms the primary interface for the user to interact and use eBPF. The reason we want to know more about this syscall is to know how to work with these cool BPF maps.

BPF Syscall

Another nice thing about eBPF is a new syscall being added to make life easier while dealing with BPF programs. In an article last year on LWN Jonathan Corbet discussed the use of BPF syscall. For example, to load a BPF program you could call

with of course, the corresponding bpf_attr structure being filled before :

Yes, this may seem cumbersome to some, so for now, there are some wrapper functions inbpf_load.c and libbpf.c released to help folks out where you may need not give too many details about your compiled bpf program. Much of what happens in the BPF syscall is determined by the arguments supported here. To elaborate more, let’s see how to load the BPF program we did before. Assuming that we have the sample program in its BPF bytecode form generated and now we want to load it up, we take the help of the wrapper function load_bpf_file() which parses the BPF ELF file and extracts the BPF bytecode from the relevant section. It also iterates over all ELF sections to get licence info, map info etc. Eventually, as per the type of BPF program – Kprobre/kretprobe or socket program, and the info and bytecode just gathered from the ELF parsing, the bpf_attr attribute structure is filled and actual syscall is made.

Creating and accessing BPF maps

Coming back to the maps, apart from this simple syscall to load the BPF program, there are many more actions that can be taken based on just the arguments. Have a look at bpf/syscall.c From the userspace side the new BPF syscall comes to the rescue and allows most of these operations on bpf_maps to be performed! From the kernel side however, with some special helper function and the use of BPF_CALL instruction, the values in these maps can be updated/deleted/accessed etc. These helpers inturn call the actual function according to the type of map – hash-map or an array. For example, here is a BPF program that just creates an array-map and does nothing else,

When loaded in the kernel, the array-map is created. Form the userspace we can then probably initialize the map with some values with a function that look likes this,

where bpf_update_elem() wrapper is in-turn calling the BPF syscall with proper arguments and attributes as,

This inturn calls map_update_elem() which securely copies the key and value using copy_from_user() and then calls the specialized function for updating the value for array-map at the specified index. Similar things happen for reading/deleting/creating has or array maps from userspace.

So probably, things will start falling into pieces now from the earlier post by Brendan Gregg where he was updating a map from the BPF program (using the BPF CALL instruction which calls the internal kernel helpers) and then concurrently accessing it from userspace to generate a beautiful histogram (through the syscall I just mentioned above). BPF Maps are indeed a very powerful addition to the system. You can also checkout more detailed and complete examplesnow that you know what is going on. To summarize, this is how an example BPF program written in restricted C for kernel part and normal C for userspace part would run these days:

In the next BPF post, I will discuss the eBPF  verifier in detail. This is the most crucial part of BPF and deserves detailed attention I think. There is also something cool happening these days on the Plumgrid side I think – the BPF Compiler Collection. There was a very interesting demo using such tools and the power of eBPF at the recent Red Hat Summit. I got BCC working and tried out some examples with probes – where I could easily compile and load BPF programs from my Python scripts! How cool is that   Also, I have been digging through the LTTng’s interpreter lately so probably another post detailing how the BPF and LTTng’s interpreters work would be nice to know. That’s all for now. Run BPF.

—
About the author of this post

Recent post by Brendan Gregg inspired me to write my own blog post about my findings of how Berkeley Packet Filter (BPF) evolved, it’s interesting history and the immense powers it holds – the way Brendan calls it ‘brutal’. I came across this while studying interpreters and small process virtual machines like the proposed KTap’s VM. I was looking at some known papers on register vs stack basd VMs, their performances and various code dispatch mechanisms used in these small VMs. The review of state-of-the-art soon moved to native code compilation and a discussion on LWN caught my eye. The benefits of JIT were too good to be overlooked, and BPF’s application in things like filtering, tracing and seccomp (used in Chrome as well) made me interested. I knew that the kernel devs were on to something here. This is when I started digging through the BPF background.

Background

Network packet analysis requires an interesting bunch of tech. Right from the time a packet reaches the embedded controller on the network hardware in your PC (hardware/data link layer) to the point they do someting useful in your system, such as display something in your browser (application layer). For connected systems evolving these days, the amount of data transfer is huge, and the support infrastructure for the network analysis needed a way to filter out things pretty fast. The initial concept of packet filtering developed keeping in mind such needs and there were many stategies discussed with every filter such as CMU/Stanford packet Filter (CSPF), Sun’s NIT filter and so on. For example, some earlier filtering approaches used a tree based model (in CSPF) to represenf filters and filter them out using predicate-tree walking. This earlier approach was also inherited in the Linux kernel’s old filter in the net subsystem.

Consider an engineer’s need to have a probably simple and unrealistic filter on the network packets with the predicates P1, P2, P3 and P4:

Filtering approach like the one of CSPF would have represented this filter in a expression tree structure as follows:

It is then trivial to walk the tree evaluating each expression and performing operations on each of them. But this would mean there can be extra costs assiciated with evaluating the predicates which may not necessarily have to be evaluated. For example, what if the packet is neither an ARP packet nor an IP packet? Having the knowledge that P1 and P2 predicates are untrue, we may need not have to evaluate other 2 predicates and perform 2 other boolean operation on them to determine the outcome.

In 1992-93, McCanne et al. proposed a BSD Packet Filter with a new CFG-bytecode based filter design. This was an in-kernel approach where a tiny interpreter would evaluate expressions represented as BPF bytecodes. Instead of simple expression trees, they proposed a CFG based filter design. One of the control flow graph representation of the same filter above can be:

The evaluation can start from P1 and the right edge is for FALSE and left is for TRUE with each predicate being evaluated in this fashion until the evaluation reaches the final result of TRUE or FALSE. The inherent property of ‘remembering’ in the CFG, i.e, if P1 and P2 are false, the path reaches a final FALSE is remembered and P3 and P4 need not be evaluated. This was then easy to represent in bytecode form where a minimal BPF VM can be designed to evaluate these predicates with jumps to TRUE or FALSE targets.

The BPF Machine

A pseudo-instruction representation of the same filter described above for earlier versions of BPF in Linux kernel can be shown as,

To know how to read these BPF instructions, look at the filter documentation in Kernel source and see what each line does. Each of these instructions are actually just bytecodes which the BPF machine interprets. Like all real machines, this requires a definition of how the VM internals would look like. In the Linux kernel’s version of the BPF based in-kernel filtering technique they adopted, there were initially just 2 important registers, A and X with another 16 register ‘scratch space’ M[0-15]. The Instruction format and some sample instructions for this earlier version of BPF are shown below:

There were some radical changes done to the BPF infrastructure recently – extensions to its instruction set, registers, addition of things like BPF-maps etc. We shall discuss what those changes in detail, probably in the next post in this series. For now we’ll just see the good ol’ way of how BPF worked.

Interpreter

Each of the instructions seen above are represented as arrays of these 4 values and each program is an array of such instructions. The BPF interpreter sees each opcode and performs the operations on the registers or data accordingly after it goes through a verifier for a sanity check to make sure the filter code is secure and would not cause harm. The program which consists of these instructions, then passes through a dispatch routine. As an example, here is a small snippet from the BPF instruction dispatch for the instruction ‘add’ before it was restructured in Linux kernel v3.15 onwards,

Above snippet is taken from net/core/filter.c in Linux kernel v3.14. Here, fentry is the socket_filter structure and the filter is applied to the sk_buff data element. The dispatch loop (136), runs till all the instructions are exhaused. The dispatch is basically a huge switch-case dispatch with each opcode being tested (143) and necessary action being taken. For example, here an ‘add’ operation on registers would add A+X and store it in A. Yes, this is simple isn’t it? Let us take it a level above.

JIT Compilation

This is nothing new. JIT compilation of bytecodes has been there for a long time. I think it is one of those eventual steps taken once an interpreted language decides to look for optimizing bytecode execution speed. Interpreter dispatches can be a bit costly once the size of the filter/code and the execution time increases. With high frequency packet filtering, we need to save as much time as possible and a good way is to convert the bytecode to native machine code by Just-In-Time compiling it and then executing the native code from the code cache. For BPF, JIT was discussed first in the BPF+ research paper by Begel etc al. in 1999. Along with other optimizations (redundant predicate elimination, peephole optimizations etc,) a JIT assembler for BPF bytecodes was also discussed. They showed improvements from 3.5x to 9x in certain cases. I quickly started seeing if the Linux kernel had done something similar. And behold, here is how the JIT looks like for the ‘add’ instruction we discussed before (Linux kernel v3.14),

As seen above in arch/x86/net/bpf_jit_comp.c for v3.14, instead of performing operations during the code dispatch directly, the JIT compiler emits the native code to a memory area and keeps it ready for execution.The JITed filter image is built like a function call, so we add some prologue and epilogue to it as well,

There are rules to BPF (such as no-loop etc.) which the verifier checks before the image is built as we are now in dangerous waters of executing external machine code inside the linux kernel. In those days, all this would have been done by bpf_jit_compile which upon completion would point the filter function to the filter image,

Smooooooth… Upon execution of the filter function, instead of interpreting, the filter will now start executing the native code. Even though things have changed a bit recently, this had been indeed a fun way to learn how interpreters and JIT compilers work in general and the kind of optimizations that can be done. In the next part of this post series, I will look into what changes have been done recently, the restructuring and extension efforts to BPF and its evolution to eBPF along with BPF maps and the very recent and ongoing efforts in hist-triggers. I will discuss about my experiemntal userspace eBPF library and it’s use for LTTng’s UST event filtering and its comparison to LTTng’s bytecode interpreter. Brendan’s blog-post is highly recommended and so are the links to ‘More Reading’ in that post.

Thanks to Alexei Starovoitov, Eric Dumazet and all the other kernel contributors to BPF that I may have missed. They are doing awesome work and are the direct source for my learnings as well. It seems, looking at versatility of eBPF, it’s adoption in newer tools like shark, and with Brendan’s views and first experiemnts, this may indeed be the next big thing in tracing.

—
About the author of this post

First off: welcome to the IO Visor Project! We are excited for the birth of this community and thrilled about the future that lays ahead of us all.

It has been over 4 years since the conception of what has now become the IO Visor Project, and it feels like a pretty adventurous journey. We’d like to take you down Memory Lane and share  how a group of end users and vendors got here and what the IO Visor Project is all about.

So … how did the IO Visor Project started?

Several PLUMgrid engineers had a vision: a dream of creating a new type of programmable data plane. This new type of extensible architecture would for the first time enable developers to dynamically build IO modules (think stand alone “programs” that can manipulate a packet in the kernel and perform all sort of functions on it), load and unload those in-kernel at run time and do it without any disruption to the system.

We wanted to transform how functions like networking or security or tracing are designed, implemented and delivered and more importantly we wanted to build a technology that would future-proof large-scale deployments with easy-to-extend functionalities.

Yes, it was an ambitious target but this is why we contributed initial IP and code to kickstart the IO Visor Project. Now, a diverse and engaged open source community is taking that initial work and running with it. A technology, compilers, a set of developers tools and real-world use case examples that can be used to create the next set of IO Module that your application and users demand.

What is so unique about it?

The developers that work on eBPF (extended Berkeley Packet Filter, the core technology behind IO Visor Project) refer to it as universal in-kernel virtual machine with run-time extensibility. IO Visor provides infrastructure developers the ability to create applications, publish them, deploy them in live systems without having to recompile or reboot a full datacenter. The IO modules are platform independent, meaning that they could run on any hardware  that uses Linux.

Running IO and networking functions in-kernel delivers the performance of hardware without layers of software and middleware. With functions running in-kernel of each compute node in a data center, IO Visor enables distributed, scale-out performance, eliminating hairpinning, tromboning and bottlenecks that are prevalent in so many implementations today.

Data center operators no longer need to compromise on flexibility and performance.

And finally … why should you care?

1. This is the first time in the history of the Linux kernel that a developer can envision a new functionality and simply make it happen.

2. Use cases are constantly changing, and we need an infrastructure that can evolve with them.

3. Software development cycles should not be longer than hardware cycle.

4. Single-node implementations won’t cut it in the land of cattle.

Where next?

Browse through iovisor.org where you will find plenty resources and information on the project and its components. Although the IO Visor Project was just formed, there is a lively community of developers who have been working together for several years. The community leverages Github for developer resources at https://github.com/iovisor

The IO Visor Project is open to all developers and there is no fee to join or participate so we hope to see many of you become a part of it!

Welcome again to the IO Visor Project!

—
About the author of this post

IO Visor Project is an IO engine with set of development tools that resides between the Linux OS and hardware, along with a set of development tools. It is an in-kernel virtual machine for IO instructions, somewhat like Java virtual machines. You see apps and a runtime engine atop a host and hardware layer. Being software defined, it has the flexibility for modern IO infrastructure and can become a foundation for new generation of Linux virtualization and networking.

Extended Berkeley Packet Filter (eBPF), the technology that underpins IO Visor, is not new but being a project hosted by the Linux Foundation will enable proliferation. It’s general purpose enough to build storage systems, distributed virtual networks or security sandboxes, but let us examine networking uses.

Don’t we have IO virtualization such as SR-IOV (Single Root I/O virtualization?) Don’t dataplane libraries such as DPDK (data plane development kit) and projects such as P4 provide flexible packet processing too? They may seem to overlap, but are actually complementary. IO Visor combines kernel-space performance with extensibility via plug ins to low level functions (e.g. DPDK or directly to hardware) so you can run IO Visor modules implemented atop DPDK.

With support of Broadcom, Cavium, Cisco, Huawei and Intel we may see plug-ins to support a variety of hardware devices. Networking endpoints have increasingly moved into virtual switches, so it is makes sense to provide IO extensibility within the kernel and not rely solely on physical switches. But physical switches are also important, and with hardware vendor support for this project, we may see IO Visor apps that span from software and hardware devices.

Linux portability gives this project a potentially large footprint. Since Linux is the basis for many network switch OSs – including those from Arista, Cisco Systems, Dell Networking, Cumulus Networks, Extreme Networks, Open Networking Linux (basis for Big Switch Networks’ Switch Light) — on the long-term, many vendors may choose to examine IO Visor.

Since IO Visor is platform independent, it can be hosted on different CPU or hardware network processing units.  SuSE and Ubuntu, as founding members, may jumpstart support for the commercial Linux community to support a variety of platforms and devices.

Here are some practical business use cases.

• Security. Performance requirements traditionally requires I/O to run in the kernel but updates were hard to make creating a tradeoff between speed and security functionality. IO Visor reduces this limitation, so I foresee the development of high performance IO security functions that can be updated with new capabilities, just like anti virus programs updating with signatures.Security use cases have used BPF for years. The popular OpenSSH utilities use it to sandbox privileges and Google’s Chrome browser on Linux and Chrome OS use it to sandbox Adobe Flash. Having it in upstream Linux should enable it find more uses.

• Cloud building blocks. Converged systems integrate storage, compute and virtualization, and will benefit from a universal IO layer. Systems like VMware vSphere distributed switches provides networking devices that spans multi hosts, but don’t offer platform independent extensibility. IO Visor enables creation of distributed virtual networks.  PLUMgrid, which contributed the initial IO Visor code, based their Open Networking Suite on this technology, so it’s known to work commercially.

• Carrier networking. Carriers support NFV in the pursuit of reducing opex, capex and increasing agility, but performance demands have been a concern. IO Visor can provide the performance with dynamic changes. Since IO Visor does not require physical or virtual appliances to create distributed networks, it can drive high density and reduced capex for carriers uses such as vCPE. Some founding member companies provide technologies to carriers, and through collaboration OPNFV, I expect carrier networking requirements will influence IO Visor development in new ways.

Foundational software systems, regardless of technical soundness, cannot succeed unless there are applications. Since the project founding members provide a wide range of solutions, we expect their contributions to build applications, tools and IO Modules and not focus solely on the IO Visor engine.

End-users won’t directly interact with IO Visor but they will instead see improvements in performance, flexibility and security and being introduced to new classes of Linux based tools and devices.

Given that Linux is used widely, we feel this project can have widespread affects throughout the Linux virtualization and networking space. With this project, another layer of the IT infrastructure may get transformed to provided more flexibility in a portable, open manner.

—
About the author of this post

In recent years, with the advent of virtualization, private and public clouds, the nature of application development and deployment has changed significantly. The demands on today’s businesses require applications to be deployed at scale in minutes, and not days, months or years. The need for agility and scale extends to the infrastructure functions needed to support these applications, like networking, storage, security and load balancing.

The advent of software defined functions, like Software-defined Networking (SDN) and Software-defined Storage (SDS), and Software-defined Security (SD-Sec), attempt to deliver on the promise of just-in-time provisioning, auto-scaling and fine grained policy control. A logical way to scale some of these IO functions is to allow them to be implemented in the host OS stack.

The IO Visor project attempts to add the ability to programmatically insert IO functions into the data plane of the Linux kernel to allow for software defined control of infrastructure needed to support modern day applications.  IO Visor requires that clearly specified data plane functions be compiled into a format that can be inserted into data plane of the Linux kernel.

Barefoot Networks has contributed to the development of P4, an open, domain specific language, that is designed to specify and program networking data planes. P4 is an imperative language that allows one to describe the data plane behavior in an intuitive manner.

P4 is the perfect high-level language to specify IO functions in IO Visor. P4 allows for concise, unambiguous, and human readable specification of IO behavior, especially when compared to alternate forms of specification using procedural languages like C. IO functions specified in P4 can be compiled into the extended Berkeley Packet Filter (eBPF) format and pushed into the data plane of the Linux kernel.

Barefoot Networks has prototyped a compiler that compiles P4 programs into LLVM IR. This LLVM IR is further compiled into eBPF using the LLVM compiler. We will contribute this compiler and the supporting tool chain to the IO Visor project by open sourcing the implementation under a permissive license. We believe that this contribution will significantly accelerate the specification of IO functions in the IO Visor project.

We look forward to a world where IO functions can be programmed easily and quickly on both virtual and physical networking infrastructures to adapt to the needs of the applications.

—
About the author of this post

Chaitanya (CK) Kodeboyina

Firewalls as intermediary networking devices have played an important role in protecting a company or organization’s internal servers and hosts, but with networking functionality virtualized (NFV), more and more company applications are moved to the public cloud and the traditional security perimeter now becomes obscure. Before the advent of virtualized firewalls, physical firewalls continued to provide security for public cloud in a similar way to traditional network design. Usually the firewall is placed in the aggregation layer and all traffic from different tenants is routed to physical firewall and the firewall obviously needs multi-tenants support (figure 1 left).

Figure 1. Physical firewall and NVF-like firewall solution in data center

With this solution the traffic between servers in two different security zones will be routed to the aggregation layer router and the firewall enforces the security policy the same way as it used to in enterprise environment. The drawback of this solution is obvious: all traffic even all internal traffic between VMs will be routed to aggregation layer that makes the system less scalable. When the traffic increases to some point that the physical firewall cannot handle, then the physical firewall has to upgraded or a load balance device added for traffic distribution.

An alternative solution to address this issue is to move the physical firewall function to NFV-like deployment, i.e. firewall running in a VM. If VMs hosting different applications need separation, they connect to the firewall NFV and the security policy will be enforced inside the VM. When there is more need, a new firewall NFV can be instantiated along with the application VMs (illustrated as figure 1 right). With NFV each tenant can be thought of as one virtual domain and security can be enforced within each tenant domain, and the traffic within one virtual domain can be optimized e.g. if all VMs are hosted in one rack, the traffic even will not go out of the rack.

When a firewall is deployed as a VM there are some challenges:

– The networking security perimeter shouldn’t change with dynamic VM migration;

– Security information should be carried along the data path within the tenant domain

– The Virtual Appliance may need to migrate to maximize the networking performance

It is non-trivial to implement all those goals with the existing infrastructure because existing configuration-based networking controllers lack the ability to distribute the traffic in a dynamic way. Controller plugins can provide some levels of programmability but the overall networking scalability issue still exists.

IO Visor creates a run-time extensible data plane that allows NFV vendors or customers to define their packet processing logic dynamically. IO visor provides the ability to create a module running in the hypervisor of each data center server and to create a virtual Fabric Overlay on top of it. By overlaying the networking dynamically and logically IO visor can keep the application VMs protected. The firewall can run either in a static networking environment or in a dynamic networking environment with IO visor platform running underneath. Additionally with IO visor’s programmability users can carry and interpret security information in their own way without NFV’s awareness, building up another layer of networking transparency to deploy the virtual security devices like NFV firewall. Finally IO visor can help optimizing the network performance, e.g. In the above example if there is a VM migration in a tenant domain and that lead to sub-optimal networking performance, the user can create its own NFV by describing networking functionality (optimization algorithm) in IO visor framework and load it run-time without waiting for the delivery from NFV vendor or any 3-rd party. This will significantly reduce the NFV delivery time.

In summary IO visor can help security via NFV-based architectures to be deployed in data center transparently and allows for more extensibility with the ability to add security features quickly.

—
About the author of this post

Immersed in the technology world, we tend to think of networking as linking machines, especially computers, to operate interactively. Before there were computers though, we might have said that networking refers to how people come together intelligently to get things done. In our hyper-connected world, open source software development is an excellent example of the latter, and increasingly a driving force behind innovation of the former.

With the announcement today at LinuxCon, SUSE is excited to be a founding member of IO Visor, an open source project and a community of developers to accelerate the innovation, development, and sharing of new IO and networking functions.

As an enterprise Linux company, our job is to produce the most reliable, secure, stable and enterprise-ready Linux on which our customers can base their entire physical and virtual infrastructure, whether they’re running their workloads in the data center, public or private cloud, or some combination of all of them.

The hybrid nature of our customers’ infrastructures is putting new pressures on the networking stack in particular. Since the physical network interface protocols vary across vendors and evolve over time, a handy thing would be to provide a “network hypervisor” that abstracts away the physical network interface thereby accommodating new requirements more easily. This would help accelerate innovation and enable enterprises to more easily deploy software defined network infrastructures.

This is what IO Visor does. Through a module that is upstream in the Linux kernel, Linux distributions like SUSE Linux Enterprise Server will be able to provide a programmable environment in which network function data planes can be loaded and instantiated at runtime, giving developers the ability to create applications, publish them, and deploy them in live systems without having to recompile. And the IO Visor solution is agnostic, not bound to any particular vendor’s hardware or software solution.

Open source software development is now the new normal for business IT, and projects like OpenStack, Open Container Initiative and Cloud Foundry are where the innovation is happening today. With the increased frequency that new open source projects are forming, we have to be judicious about which ones we elect to participate in, and we put a high priority on those that will help to solve challenges that our customers have today. IO Visor is such a project.

—
About the author of this post