Tag-Based Classification for Software-Defined Networking

Tag-Based Classification for Software-Defined Networking

Hamid Farhady (The University of Tokyo, Tokyo, Japan) and Akihiro Nakao (The University of Tokyo, Tokyo, Japan)
Copyright: © 2015 |Pages: 14
DOI: 10.4018/ijghpc.2015010101
OnDemand PDF Download:
$30.00
List Price: $37.50

Abstract

Software-Defined Networking (SDN) increasingly attracts more researchers as well as industry attentions. Most of current SDN packet processing approaches classify packets based on matching a set of fields on the packet against a flow table and then applying an action on the packet. The authors argue that it is possible to simplify this mechanism using single-field classification and reduce the overhead. They propose a tag-based packet classification architecture to reduce filtering and flow management overhead. Then, they show how to use this extra capacity to perform application layer classification for different purposes. The authors demonstrated their evaluation results to indicate the effectiveness of the proposal. Furthermore, they implemented a customized user-defined SDN action that addresses some security challenges of one of their previous works and showed performance evaluation results.
Article Preview

1. 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.

Complete Article List

Search this Journal:
Reset
Open Access Articles: Forthcoming
Volume 9: 4 Issues (2017)
Volume 8: 4 Issues (2016)
Volume 7: 4 Issues (2015)
Volume 6: 4 Issues (2014)
Volume 5: 4 Issues (2013)
Volume 4: 4 Issues (2012)
Volume 3: 4 Issues (2011)
Volume 2: 4 Issues (2010)
Volume 1: 4 Issues (2009)
View Complete Journal Contents Listing