OF-DPA文档读后感

OF-DPA整体架构？

OF-DPA是库。如上左图片显示了使用OF-DPA的软件架构，用户通过控制器控制OF-DPA软件。在OF-DPA软件中，OpenFlow Agent接受openflow消息，将所要添加的flow通过OF-DPA API传递给OF-DPA，这个API应该是按照table来定义的。与ovs-TTP不同，ovs-TTP没有提供OF-DPA API这一层。

下面这张图显示了OF-DPA中详细结构，包括三层：API层；OFDB层；Datapath层；Mapping/Driver层；platform层。

API模块表示北向OF-DPA API，可以通过RPC与直接调用两种方式，用户不同使用CLI方式访问API，而必须通过上述两种方式。后面use case中配置一些flow的方式就是使用JSON-RPC。在OF-DPA中，使用CLI（client_XXX，见下）添加flow的时候并不指定table-id，在ovs-ovs中添加flow的时候需要指定table-id。而在OF-DPA的JSON-RPC方式中，需要通过json字符串中table字段指定table的名字，而不ovs-ovs中的table id。

OFDB模块表示OF-DPA database。这个database存储了flow、group、port tables，并提供API来操作database，其中内容包括：add/delete的flow；mapping信息，例如port的状态等，这个相当于ovs8的vswitchd.ovsschema；datapath的信息，例如上一次做flow aging的时间。这个模块整体相当于ovs中的ovsdb-server。

datapath用来实现周期性的检查硬件flow的计数、删除过期的硬件flow。这是一个周期性事件驱动的模块。类似于ovs的revalidator。

Mapping/Driver，SDK初始化、SDK抽象层。

platform，包括OF-DPA的初始化的配置，相当于ovs_dev_info.conf。

OF-DPA库组成？

OF-DPA库有interprocess与static两种方式。有一系列client程序通过RPC访问OF-DPA库的API层。

<p>

* client_acl: installs entries in the Policy ACL Flow Table

* client_bridging: installs entries in the Bridging Flow Table.

* client_debugcomp: enables/disables component debugging mode. Refer to ofdpaDebugComponentSet() and ofdpaDebugComponentGet()

* client_debuglvl: sets OF-DPA debug verbosity. Refer ofdpaDebugLvl() and ofdpaDebugLvlGet()

* client_event: sample program to receive events from OF-DPA

* client_flowtable_dump: prints flow table entries

* client_pkt_txrx: sample program to receive and transmit packets from and to OF-DPA

* client_port: configures and gets port configuration

* client_routing: installs entries in the Unicast Routing Flow Table and the Multicast Routing Flow Table

* client_srcmac_learn: enables, disables Source MAC learning mode of OF-DPA

* client_termmac: installs entries in the Termination MAC Flow Table

* client_vlan: installs entries in the VLAN Flow Table

* client_group: creates action Groups

* client_tunnel_tenant: creates a tenant

* client_tunnel_ecmp_nexthop: creates a Tunnel ECMP next hop group

* client_tunnel_ecmp_nexthop_member: adds Tunnel ECMP next hop group members

* client_tunnel_nexthop: creates Tunnel next hop

* client_tunnel_port: creates Tunnel logical ports

* client_tunnel_port_tenant: adds the tunnel logical ports to a tenant

* client_cfg_purge: purges entries from all the flow tables and groups

* client_ingress_port: adds an ingress port flow

</p>

一个简单的例子，使用openflow1.0与使用OF-DPA + openflow1.3哪个好？

如上图的拓扑，下面ingress阶段是4个host发TCP包，目的地址是192.168.5.1，有4k个L4源端口，可用于loadbalance。现在管理员想要在switch上下发flow，使得ingress进来的IP包采用loadbalance的方式从上面egress port出去。

使用openflow1.0的switch时候，需要如下配置：

<p>

1. 首先配置使用L4源端口作为loadbalance的因子。

2. 需要4k条flow：“ip,nw_addr=192.168.5.1,tcp_src_port=x,actions=output:y”，其中x是4k个L4源端口，y是egress port。

3. 在controller端需要运行loadbalance算法。

综上，共使用一个table，4k条flow。

</p>

而使用OF-DPA + openflow1.3，时候，需要如下配置：

<p>

1. 在vlan table中配置4个flow：“in_port=x,vlan=all,actions=goto TerminationMac Table”。这里与ovs-TTP的vlan table配置flow的方式不同。

2. 在TerminationMac Table中配置一个flow：“dst_mac=x,vlan=all,actions=goto Route Table”。

3. 添加一个ECMP group。这里使用硬件ECMP功能，使得controller不必再运行loadbalance算法。

4. 在route table中添加一条flow：“nw_dst=x,actions=ECMP group”。

综上，只需要在3个table和1个group table中添加若干条flow即可，同时controller也不必要运行任何算法。

</p>

综上分析，使用OF-DPA更加简便。另外OF-DPA通过API层，可以接收JSON格式的flow mod，有一个例子就是使用Ryu控制switch中的flow，这点ovs-TTP不能做到。