Article Preview
Top1. Introduction
Software-Defined Networking (SDN) increasingly attracts more researchers as well as industry attentions. Last year, Google announced that it is using SDN to improve their internal network between data centers. An out of the box outline of SDN roadmap shows significant improvements in network control and management. While there are many efforts towards developing control plane architecture and applications such as OpenFlow (OpenNetworkingFoundation, 2012), ForCES (Yang et al., 2005) and rule based forwarding (Popa, Egi, Ratnasamy, & Stoica, 2010), there is a limited attention to design effective APIs and methods for data plane.
OpenFlow is a wide-spread API for Software-Defined Networking. This API installs a set of <match, action> rules on network switches. Any flow matching to the rule, receives the corresponding action. The matching process classifies particular flows for the action. Similar to many other protocols (e.g., SNMP (Stallings, 1998)) to classify incoming flows, OpenFlow parses the packet against predefined protocol headers (e.g., Ethernet, IP and TCP). Then, it matches extracted fields against a set of rules. If enough fields match to a rule, it applies the corresponding action (e.g., drop or forward to port X) to the packet. One of the problems in this process is that the protocol headers should be predefined. Updating such patterns in a timely fashion as well as keeping the performance at a reasonable level is not a trivial task. Because of performance considerations, matching process is implemented on hardware (e.g., Ternary Content Addressable Memory).
1.1. Flexibility of Flow Classification
An obvious solution is to support more protocols via adding more fields. Probably this is the solution OpenFlow is following. It is also possible to add some general fields (i.e., smarter wildcard rules) so that users can freely add arbitrary bits to the packet bit stream. The process of adding fields may (practically) converge after a decade. Before convergence, hardware upgrades may cause some overhead costs for users. That is, the same problem current hardware-centric networks suffer from. If we neglect all these issues, flexibility of flow classification can be a major shortcoming. Low level classification based on some static or wildcard matching rules suffer from inflexibility. Furthermore, traditional header matching is already overloaded in different ways. For example, port 80 is now used for many applications that can have different processing/forwarding requirements. We cannot classify these applications easily using field-matching classification of OpenFlow. This is the main drawback of field-matching classification. Hence, any extra support for emerging protocols is costly.