2.2 KiB
Project Overview
This project is an OpenFlow agent written in C. It implements a subset of the OpenFlow 1.3 protocol to allow a remote controller to manage a network switch. The agent is designed to run on an ARM-based device.
The core logic resides in main_user_openflow.c, which handles various OpenFlow message types such as HELLO, FEATURES_REQUEST, GET_CONFIG_REQUEST, and PACKET_OUT. The agent responds to these messages by sending back appropriate replies, allowing the controller to inspect and manage the switch's state.
The project is built using a Makefile and links against several local libraries, including libofp (for OpenFlow protocol handling) and libnet (for network packet manipulation).
Building and Running
Building
To build the project, you can use the provided Makefile. The Makefile uses the arm-linux-gnueabihf-gcc cross-compiler, so you'll need to have that installed and in your PATH.
# To build the project
make
This will create an executable file named user_openflow in the project's root directory.
Running
The user_openflow executable can only be run on the target ARM device. Based on the comment at the end of main_user_openflow.c, the following command can be used to run the agent:
sudo ./user_openflow -c eth0 -i obx0,obx1,obx2,obx3
-c eth0: Specifies the control interface.-i obx0,obx1,obx2,obx3: Specifies the data plane interfaces.
The agent will then listen for incoming connections from an OpenFlow controller.
Development Conventions
- Coding Style: The code follows a C-style with a focus on clarity and modularity. Functions are well-documented with comments explaining their purpose, parameters, and return values.
- Testing: There is a Python script
openflow_flow-test.py, which suggests that testing is done using Python scripts. - Dependencies: The project relies on several pre-compiled libraries located in the
lib/directory. Any new dependencies should be added there. - Architecture: The main application logic is event-driven, with a central callback function that dispatches OpenFlow messages to their respective handlers. This makes it easy to extend the agent by adding new handlers for additional OpenFlow message types.