An IP network element is composed of numerous logically separate entities that cooperate to provide a given functionality (such as a routing or IP switching) and yet appear as a normal integrated network element to external entities. Two primary types of network element components exist: control-plane components and forwarding-plane components.
IETF’s new draft standards, Forwarding and Control Element Separation (ForCES), separates the Forwarding and the Control Plane, by specifying both a protocol and a model. The ForCES model is described in an XML schema (XSD) and is used to specify data path components responsible for packet processing functions. The protocol operates on the model-defined data path components. Two vendors implementing ForCES, one providing a Forwarding Element (FE) and another providing a Control Element (CE) inter-operate to build a packet processing NE such as a router, firewall etc. The separation allows rapid innovation in both planes while maintaining interoperability. You can download a small presentation of ForCES [ here ].
Openflow similar to ForCES separates the control and forwarding plane, by providing an open protocol, to control OpenFlow switches. An OpenFlow Switch consists of one or more flow tables and a group table, which perform packet lookups and forwarding, and an OpenFlow channel to an external controller. The controller manages the switch via the OpenFlow protocol. Using this protocol, the controller can add, update, and delete flow entries. A flow table is consisted of flow entries, each containing a set of match fields to match against packets, counters and instructions. While the OpenFlow protocol has many similarities to the ForCES protocol, OpenFlow limits the modeling of the data plane to specific flow tables per each OpenFlow protocol specification.
Our research project aims to create an Open Distributed Network Element, comprising of multiple Forwarding Elements and multiple Control Elements.
Our current implementation [ presentation slides ] includes a major part of the ForCES architecture and includes:
- A minimal CE implementation in Java that can connect to any FE and send any kind of ForCES message, configured by a text file. For the CE we have implemented the CE High Availability function for standby.
- For FEs we have implemented in C++ a generic scalable LFB architecture where you can build any kind of LFB without the need to write extra ForCES code. There is no API to send the commands to the hardware, it’s only dummy LFBs that speak ForCES and comply with ForCES commands.
We intentionally didn’t target a specific hardware platform, since we wanted to provide a generic ForCES architecture.
For the CE in Java there was a need to create unsigned types.
As implementors of the ForCES framework we have successfully participated in both the first two ForCES interoperability tests (hosted the first).
Future Goals:
- Use NetFPGAs to implement a ForCES FE.
- Develop a ForCES layer for the control plane and for the forwarding plane.
- Investigate extend the OpenFlow protocol with ForCES concepts.
For more information or questions contact us at: ehalep [at] ece.upatras.gr