On IPv6 support in OpenFlow via Flexible Match Structures
Rodrigo R. Denicol, Eder Leão Fernandes, Christian Esteve Rothenberg, Zoltán Lajos Kis · 2011
As is so common in technologies, low cost/performance and flexibility conflict with each other. While software-only routers lack of performance, network processors are regarded as too complex to program, and hardware-based designs (including commodity silicon) have been too inflexible [4]. Recognizing the different tradeoffs between these goals, recent efforts [4, 7] advocate for a path towards flexible and efficient networking gear based on co-evolving router hardware, extensible router software, and a clean interface between them. For the latter, OpenFlow [3] is considered the best candidate API available to unveil true innovation in networking. Up to recently, the OpenFlow specification has worked with fixed tupples (10 in v1.0 and 12/14 in v1.1) limiting the available match fields to a hardwired subset of fields in the protocol stack. The rigid flow match structure specification is considered a risk to the protocol success and endangers the promise of future-proof independent evolvability of the data and control planes. To turn this over, OpenFlow 1.1 introduces experimenter features that allow extensible matches, actions, messages, and errors. The ability of extending the flow match structure by defining new types of Flow Match Structures (see A.2.3 [3]) allows controllers and switches to agree on any flow matching syntax. IPv6 [6] was designed with extensibility in mind. In addition to more efficient forwarding,the improved support for extensions and options in IPv6 allows a greater flexibility for introducing new options in the future. Basically, the functionality of options and other rarely used fields is removed from the main header in IPv4 and implemented in IPv6 through a set of additional headers called extension headers (EH), some of them based on a variable number of “options” encoded in TLV format. When IPv6 EHs are to be supported in OpenFlow, a packet field above the base IP header may then occur at different bit positions. The extra switch complexity required for IPv6 EH has two main disadvantages: One is an obvious increase in switch production costs. The other is a higher