Hi,
OPNFV DPACC team is trying to standardize the flow API, that would be called from VNFs to talk to flow processing modules in VMM or smart-NIC.
One discussion group was started. You are welcome to join this group here:
https://app.pivot-it.com/Public/Open-flow-based-distributed-data-path-for-virtualised-data-centers-openflowdatapath/enter/
Why flow flow API from VNFs : NFV success depends on the performance VNFs can achieve. Many are feeling that NFV flexibility is great, but to achieve similar performance as physical appliances, one needs to have 2x to 10x hardware. Even with lot more hardware, one can achieve throughput, but issues remain in achieving low packet latency and low packet jitter. Since, NFV uses generic hardware, cost may not go up (in comparison with physical appliances), but the electricity charges related to powering more hardware and cooling would go up. Also, space requirements also go up which can add to the cost of operations.
OVS acceleration using DPDK and smart-NICs are addressing this issue by accelerating or offloading virtual switching functionality. 1/2 of the problem is take care by this. Another 1/2 of the problem is packet processing by VNFs. There are many VNFs, that follow CP-DP model where DP can be offloaded. Many smart-NIC solution want to take care of that too. But lack of standards is dampening these efforts. In NFV environments, vNFs and smart-NICs are coming from two different parties. VNFs can be placed in many servers with smart-NICs of various vendors. VNF vendors would not like to have drivers for various smart-NICs. Also, smart-NIC vendors would not like to provide drivers for various VNF operating systems and their versions. Operators, who are procuring these also would not want to worry about any inter-dependencies. That is where, standardization helps.
Another bigger issue in NFV markets is that type of VNFs that are going to be placed on a given server. The type of VNFs on a server keep changing with the time. Since the type of VNFs are not known a priori,
OPNFV DPACC team is trying to standardize the flow API, that would be called from VNFs to talk to flow processing modules in VMM or smart-NIC.
One discussion group was started. You are welcome to join this group here:
https://app.pivot-it.com/Public/Open-flow-based-distributed-data-path-for-virtualised-data-centers-openflowdatapath/enter/
Why flow flow API from VNFs : NFV success depends on the performance VNFs can achieve. Many are feeling that NFV flexibility is great, but to achieve similar performance as physical appliances, one needs to have 2x to 10x hardware. Even with lot more hardware, one can achieve throughput, but issues remain in achieving low packet latency and low packet jitter. Since, NFV uses generic hardware, cost may not go up (in comparison with physical appliances), but the electricity charges related to powering more hardware and cooling would go up. Also, space requirements also go up which can add to the cost of operations.
OVS acceleration using DPDK and smart-NICs are addressing this issue by accelerating or offloading virtual switching functionality. 1/2 of the problem is take care by this. Another 1/2 of the problem is packet processing by VNFs. There are many VNFs, that follow CP-DP model where DP can be offloaded. Many smart-NIC solution want to take care of that too. But lack of standards is dampening these efforts. In NFV environments, vNFs and smart-NICs are coming from two different parties. VNFs can be placed in many servers with smart-NICs of various vendors. VNF vendors would not like to have drivers for various smart-NICs. Also, smart-NIC vendors would not like to provide drivers for various VNF operating systems and their versions. Operators, who are procuring these also would not want to worry about any inter-dependencies. That is where, standardization helps.
Another bigger issue in NFV markets is that type of VNFs that are going to be placed on a given server. The type of VNFs on a server keep changing with the time. Since the type of VNFs are not known a priori,
- One way to address is to provide all kinds of fast path functions in smart-NICs. That is very complicated, not only with respect to number of functions, but also with respect to keeping it up with newer VNF and related fast path functions.
- Second way is to let the VNFs install their own fast paths in smart-NIC. That is also challenging as there are multiple smart-NIC vendors. It is a complexity for vNF vendors to provide fast path functions for multiple smart-NIC vendors. It is also a complexity for smart-NIC vendors to ensure that malicious VNF fast path does not hinder its operations. Few people are exploring the ways to use eBPF based fast path functions. Since eBPF comes with some kind of verification of program to ensure that it does not hinder other operations, many think that this could be one approach.
- Third way is to define generic pipeline of packet stages with dynamic flow programming. Similar to Openflow, but with reduced complexity of Openflow. Smart-NIC vendors only need to provide flow processing entity. All the intelligence of using flow processing entity is up to the VNFs. VNFs don't push any software entity in smart-NIC. With this mechanism, smart-NIC can be a network processors, AIOP, FPGA etc..
Above discussion forum is trying to create generic flow API that can be used by VNFs to program tables, flows with actions, objects etc..
Please join the group and let us discuss technical items there. Once we have some clarity, then we intend to present this to OPNFV DPACC forum.
Thanks
Srini
No comments:
Post a Comment