This repository is no longer maintained. If you want to integrate a P4 dataplane with an SDN controller, you can take a look at the ONOS project.
This is the controller-facing layer of a P4 agnostic Openflow 1.3 Agent.
+-----------------------------------+
| Openflow Controller |
| |
+-----------------------------------+
^
|
|
v
+-----------------------------------+
| Openflow Agent |
| |
|-----------------------------------|
| Openflow <-> P4 Mapping |
+-----------------------------------+
| Resource Mgmt. API |
| (auto-gen. from p4 program) |
+-----------------------------------+
| Soft Switch |
| (compiled from p4 program) |
+-----------------------------------+
To build, run
git submodule update --init --recursive
./autogen.sh
./configure
This generates a Makefile with target p4ofagent
to be required by a
p4factory target Makefile.
For use with BMV2, the P4 Openflow Agent needs to be installed. First install
BMV2, then follow the
above instructions for building, but with CPPFLAGS=-D_BMV2_ exported in your environment.
Note that when running ./configure
for bmv2, you need to provide the --with-pdfixed
option, as p4ofagent
requires the PD library.
Then run make p4ofagent
and make install
.
The P4 Openflow Agent is P4-independent, so features vary with the
source P4 program. With everything enabled, the openflow.p4
module supports:
-
Forwarding
-
Multicast (OFPGT_ALL) groups.
-
Vlan push/pop/set
-
MPLS push/pop/ttl-set
-
Network ttl set
-
Packet in, packet out
The P4 Openflow Agent depends on the PD (Protocol Dependent) API generated by the P4 compiler when building a p4factory target. It is intended to be used as a submodule to p4factory.
There is an openflow.p4
file in the p4src/
directory of this repo. A copy
of this file lives in the
switch
target of p4factory, where Openflow integration is already done. But you will
probably have to edit it slightly for other targets. In particular, packet-in
and packet-out must be enabled by uncommenting the OPENFLOW_PACKET_IN_OUT
macro, which protects fabric header definitions and related parsers/actions.
This has been done for the
l2_switch
target as an example.
openflow.p4
defines two "public" actions, openflow_apply
and openflow_miss
.
These must be included in an Openflow table's action set. The
process_ofpat_ingress
control block must be called from within the target's
ingress control flow, and the process_ofpat_egress
control block must be called
from within the target's egress control flow. Finally, the packet_out
table
should be applied appropriately in the ingress control flow with a definition of
the nop
action to take on a miss, but this is subject to programmer discretion.
Note that to enable features such as VLAN and MPLS, the header declarations must be added if not present, and modifications to the source program's parser must to be made to unpack these headers.
When adding Openflow to a target, you must write a mapping file that tells the behavioral model which P4 tables to expose as Openflow tables. This keeps the P4 Openflow Agent P4-independent. The mapping file enumerates the tables to expose as Openflow tables and each tables' match fields, along with their corresponding Openflow types per the Openflow 1.3 specification.
Edit the target Makefile to build and link this library, then add a call to
p4ofagent_init
(defined in p4ofagent.c
) to the main.c
that is starting
the behavioral model. This will start the P4 Openflow Agent as a thread in
the behavioral model. Then you're done! Whew!
To play with a live example, see the mininet script written for use with the Ryu opensource openflow controller. To run it, build the switch target with the Openflow Agent, then start a Ryu instance running the simple_switch_13 app in another window.